Re: [U-Boot] [PATCH v3 00/11] arm: add Faraday A36x SoC platform support
2013/5/3 Tom Rini :
> On Fri, Apr 26, 2013 at 04:02:29PM +0800, Kuo-Jung Su wrote:
>
>> From: Kuo-Jung Su
>>
>> To: u-boot@lists.denx.de
>> CC: Albert Aribaud
>>
>> These patches introduce Faraday A36x SoC platform support.
>>
>> Here are some public documents for your reference.
>>
>> http://www.faraday-tech.com/html/documentation/index.html
>>
>> There is also a A369 QEMU emulator available at my github account:
>>
>> https://github.com/dantesu1218/qemu.git
>>
>> Here is quick start for QEMU:
>>
>> 1. Download the QEMU source tree
>>
>> $ git clone -b qemu-1.3.0 https://github.com/dantesu1218/qemu.git
>>
>> 2. Build & Install the QEMU:
>>
>> $ ./configure --target-list=arm-softmmu
>> $ make
>> $ make install
>>
>> 3. Launch u-boot with QEMU:
>>
>> $ qemu-system-arm -M a369 -m 512M -nographic -kernel
>> ~/u-boot-devel/u-boot
>>
>> Changes for v3:
>>- Coding Style cleanup.
>> There is still one warnning reported by checkpatch.pl,
>> however it's too deep for me to fix it.
>> Here is the shapshot for it:
>> -
>> WARNING: do not add new typedefs
>> #9735: FILE: include/lcd.h:258:
>> +typedef struct vidinfo {
>> -
>>- Drop bit fields from c struct.
>>- Drop macros for wirtel()/readl(), call them directly.
>>- Always insert a blank line between declarations and code.
>>- Replace all the infinite wait loop with a timeout.
>>- Add '__iomem' to all the declaration of HW register pointers.
>>- cmd_boot.c: Make it a separate stand-alone patch.
>>- ftspi020: Make it a separate stand-alone patch.
>>- dma-mapping.h: Have the global data ptr declared outside functions.
>>- dma-mapping.h: Add #if...#else...#endif to dma_free_coherent().
>>- MMU/D-Cache: Drop static non-cached region, now we use
>> map_physmem()/unmap_physmem() for dynamic mappings.
>>- ftmac110: Make a correction to multi-line comment style
>>- ftmac110: Use random MAC address while having trouble
>> to get one from environment variables.
>>- ftmac110: Add comments to timing control registers.
>>- ftnandc021: Re-write this driver with ECC enabled and
>> correct column address handling for OOB read/write,
>> and fixing issused addressed by Scott.
>>- a36x_config: No more static global network configurations.
>>- a36x_config: Add a common file for the redundant configurations.
>
> I see a few:
> /*
> * Comment
> */
It's used in ftssp010_spi.c only, and it would be removed later.
> in various places, and I pointed it out in the net changes, but I also
> saw in the SPI block '100' being used as a timeout, rather than defined.
> Please give everything a check for magic numbers and direct numbers used
> as timeout, rather than a #define.
>
Got it, thanks
> --
> Tom
--
Best wishes,
Kuo-Jung Su
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/11] net: add Faraday FTMAC110 10/100Mbps ethernet support
2013/5/3 Tom Rini :
> On Fri, Apr 26, 2013 at 04:02:32PM +0800, Kuo-Jung Su wrote:
>
>> From: Kuo-Jung Su
> [snip]
>> + | (phyaddr << PHYCR_ADDR_SHIFT)
>> + | (phyreg << PHYCR_REG_SHIFT)
>> + | 0x3000;
>
> Magic number.
>
It's the HW debug function, it would be removed at next version.
>> +
>> + writel(tmp, ®s->phycr);
>> +
>> + for (ts = get_timer(0); get_timer(ts) < 1000; ) {
>
> Please define a TIMEOUT and use that insteadof 1000 all the time.
>
Got it, thanks
> [snip]
>> + /* interrupt at every packet transmit/receive */
>> + writel(0x1010, ®s->itc);
>> + /* tx/rx poll interval=5.12us; rx_poll_cnt=1 */
>> + writel(0x0001, ®s->aptc);
>> + /* rx fifo: high=1536, low=512 */
>> + writel(0x0390, ®s->dblac);
>> + /* clear all interrupt status */
>> + writel(0x03FF, ®s->isr);
>
> More magic numbers. Please fix globally. Thanks!
>
Got it, thanks
> --
> Tom
--
Best wishes,
Kuo-Jung Su
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: mxc_spi: Fix pre and post divider calculation
On 02.05.2013 20:38, Troy Kisky wrote:
On 5/2/2013 3:59 AM, Dirk Behme wrote:
From: Dirk Behme
Fix two issues with the calculation of pre_div and post_div:
1. pre_div: While the calculation of pre_div looks correct, to set the
CONREG[15-12] bits pre_div needs to be decremented by 1:
The i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM
Rev. 0, 11/2012) states:
CONREG[15-12]: PRE_DIVIDER
Divide by 1
0001 Divide by 2
0010 Divide by 3
...
1101 Divide by 14
1110 Divide by 15
Divide by 16
I.e. if we want to divide by 2, we have to write 1 to CONREG[15-12].
2. In case the post divider becomes necessary, pre_div will be set to 15. To
calculate the post divider, divide by 15, too. And not 16.
Both issues above are tested using the following examples:
clk_src = 6000 (60MHz, default i.MX6 ECSPI clock)
a) max_hz == 2300 (23MHz, max i.MX6 ECSPI read clock)
-> pre_div = 3 (divide by 3 => CONREG[15-12] == 2)
-> post_div = 0 (divide by 1 => CONREG[11- 8] == 0)
=> 60MHz / 3 = 20MHz SPI clock
b) max_hz == 200 (2MHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 1 (divide by 2 => CONREG[11- 8] == 1)
=> 60MHz / 30 = 2MHz SPI clock
c) max_hz == 100 (1MHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 2 (divide by 4 => CONREG[11- 8] == 2)
=> 60MHz / 60 = 1MHz SPI clock
d) max_hz == 50 (500kHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 3 (divide by 8 => CONREG[11- 8] == 3)
=> 60MHz / 120 = 500kHz SPI clock
Signed-off-by: Dirk Behme
---
drivers/spi/mxc_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 5bed858..8630bbd 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -128,7 +128,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
unsigned int max_hz, unsigned int mode)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
- s32 pre_div = 0, post_div = 0, i, reg_ctrl, reg_config;
+ s32 pre_div = 1, post_div = 0, i, reg_ctrl, reg_config;
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs->base;
@@ -153,7 +153,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
if (clk_src > max_hz) {
pre_div = DIV_ROUND_UP(clk_src, max_hz);
if (pre_div > 16) {
- post_div = pre_div / 16;
+ post_div = pre_div / 15;
I think this should not change
Hmm, why? You get wrong post_div dividers if you run with 'pre_div = 15'
and '/16'. Hmm, reading your below comment do you want to say
"I agree that both lines
post_div = pre_div / 16;
pre_div = 15;
have to use the same value, but instead of using 15, use 16
"
?
pre_div = 15;
and this should be = 16, because you now subtract 1 below
Do you want to say you propose
post_div = pre_div / 16;
pre_div = 16;
?
If so:
First, I agree that we have to use the same dividers in both lines.
But, second, this would mean that you use /16 as max pre_div. For the
i.MX6 case where clk_src is 60MHz this would result in a pre-divided
clock of 3.75Mhz (instead of 4MHz with /15).
So using /15 or /16 is just a decision of which end clocks most probably
are needed.
If you want to be able to configure 4MHz, 2MHz, 1MHz, 500kHz etc then
/15 is the better choice.
If you want to be able to configure 3.75Mhz, 1.875MHz, 937.5kHz,
468.75kHz etc then /16 is the better choice.
I vote for /15 as done by my patch.
Best regards
Dirk
}
if (post_div != 0) {
@@ -174,7 +174,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_SELCHAN(3)) |
MXC_CSPICTRL_SELCHAN(cs);
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_PREDIV(0x0F)) |
- MXC_CSPICTRL_PREDIV(pre_div);
+ MXC_CSPICTRL_PREDIV(pre_div - 1);
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_POSTDIV(0x0F)) |
MXC_CSPICTRL_POSTDIV(post_div);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
==
Dirk Behme Robert Bosch Car Multimedia GmbH
CM-AI/PJ-CF32
Phone: +49 5121 49-3274 Dirk Behme
Fax: +49 711 811 5053274 PO Box 77 77 77
mailto:dirk.be...@de.bosch.com D-31132 Hildesheim - Germany
Bosch Group, Car Multimedia (CM)
Automotive Navigation and Infotainment Systems (AI)
ProJect - CoreFunctions (PJ-CF)
Robert Bosch Car Multimedia GmbH - Ein Unternehmen der Bosch Gruppe
Sitz: Hildesheim
Registergericht: Amtsgericht Hil
Re: [U-Boot] [PATCH v1] bfin: Move gpio support for bf54x and bf60x into the generic driver folder.
Hi Mike, On Fri, May 3, 2013 at 12:23 AM, Mike Frysinger wrote: > On Thursday 02 May 2013 01:55:25 Sonic Zhang wrote: >> The gpio spec for bf54x and bf60x differ a lot from the old gpio driver for >> bf5xx. A lot of machine macros are used to accomodate both code in one >> gpio driver. This patch split the old gpio driver and move new gpio2 >> support to the generic gpio driver folder. >> >> - To enable gpio2 driver, macro CONFIG_ADI_GPIO2 should be defined in the >> board's config header file. >> - The gpio2 driver supports bf54x, bf60x and future ADI processors, while >> the older gpio driver supports bf50x, bf51x, bf52x, bf53x and bf561. >> - All blackfin specific gpio function names are replaced by the generic >> gpio APIs. > > the code in u-boot was written so as to make direct import from the kernel > trivial. that way there is only one code base to maintain -- the kernel. > last i looked, you hadn't split the drivers in the kernel, which means things > are now diverging. Don't worry. I will do it in Linux kernel soon after this is merged into u-boot. Regards, Sonic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] EXYNOS: SPI: Support SPI_PREAMBLE mode
[the original patch removed, re-sending from a registered address]
So, I spent some more time debugging a system which requires this
patch: a system, where on a SPI interface a response to a command
could come way later then the command data transmission completes.
The original patch was trying to address many corner cases, but come
to think of it, in this situation the slave does not care about extra
data sent on the transmit interface, as otherwise there is no clock
and no data could be transferred from the slave.
Then, for this SPI interface we do not need to set the counter of
clocks, and do not need to keep adding more clocks if the data has not
been received yet, the clocks could be just free running. And then the
patch becomes much simpler, what do you think:
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index c697db8..fff8310 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -211,10 +211,10 @@ static void spi_get_fifo_levels(struct exynos_spi *regs,
*/
static void spi_request_bytes(struct exynos_spi *regs, int count)
{
- 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);
+ if (count)
+ writel(count | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
}
static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
@@ -225,14 +225,20 @@ static void spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
const uchar *txp = *doutp;
int rx_lvl, tx_lvl;
uint out_bytes, in_bytes;
-
+ int hunting;
+
+ if (spi_slave->free_running_mode) {
+ spi_request_bytes(regs, 0);
+ hunting = 1;
+ } else {
+ hunting = 0;
+ spi_request_bytes(regs, todo);
+ }
out_bytes = in_bytes = todo;
- /*
-* If there's something to send, do a software reset and set a
-* transaction size.
-*/
- spi_request_bytes(regs, todo);
+ /* Software reset the channel. */
+ setbits_le32(®s->ch_cfg, SPI_CH_RST);
+ clrbits_le32(®s->ch_cfg, SPI_CH_RST);
/*
* Bytes are transmitted/received in pairs. Wait to receive all the
@@ -243,13 +249,23 @@ static void 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) {
- temp = txp ? *txp++ : 0xff;
+ if (tx_lvl < spi_slave->fifo_size) {
+ if (txp && out_bytes) {
+ temp = *txp++;
+ out_bytes--;
+ } else {
+ temp = 0xff;
+ }
writel(temp, ®s->tx_data);
- out_bytes--;
}
if (rx_lvl > 0 && in_bytes) {
temp = readl(®s->rx_data);
+ if (hunting) {
+ if ((temp & 0xff) != PREAMBLE_VALUE)
+ continue;
+ else
+ hunting = 0;
+ }
if (rxp)
*rxp++ = temp;
in_bytes--;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] EXYNOS: Convert Assembly code to c and make it common.
Hi Minkyu Kang,
Do let me know if any comments on this patch set.
Regards,
Rajeshwari Shinde.
On Thu, Apr 25, 2013 at 11:27 AM, Rajeshwari Shinde
wrote:
> Convert the assembly code in board/samsung to c and move the same to arch/arm.
> lds file made common across SMDKV310, Origen and SMDK5250.
> Add the power reset and exit wakeup api for exynos.
> Initialise GPIO for uart in Origen and SMDK5250 using pinmux.
>
> Rajeshwari Shinde (4):
> EXYNOS: Add API for power reset and exit wakeup
> EXYNOS: LDS file move to common
> EXYNOS4210: Configure GPIO for uart
> EXYNOS: Move files from board/samsung to arch/arm.
>
> arch/arm/cpu/armv7/exynos/Makefile | 14 +-
> .../arm/cpu/armv7/exynos}/clock_init.h |0
> arch/arm/cpu/armv7/exynos/clock_init_exynos4.c | 63 +++
> .../arm/cpu/armv7/exynos/clock_init_exynos5.c | 26 +-
> arch/arm/cpu/armv7/exynos/common_setup.h | 44 ++
> .../arm/cpu/armv7/exynos}/dmc_common.c |7 +-
> .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c | 17 +-
> arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c | 294
> .../arm/cpu/armv7/exynos/exynos4_setup.h | 72 +++-
> .../arm/cpu/armv7/exynos/exynos5_setup.h | 53 +--
> arch/arm/cpu/armv7/exynos/lowlevel_init.c | 72 +++
> arch/arm/cpu/armv7/exynos/pinmux.c | 40 ++
> arch/arm/cpu/armv7/exynos/power.c | 50 ++
> .../arm/cpu/armv7/exynos}/spl_boot.c | 90 +++-
> .../arm/cpu/armv7/exynos}/tzpc_init.c | 17 +-
> arch/arm/include/asm/arch-exynos/power.h | 10 +
> arch/arm/include/asm/arch-exynos/spl.h |1 +
> arch/arm/include/asm/arch-exynos/tzpc.h| 28 ++
> .../exynos-uboot-spl.lds} |0
> board/samsung/origen/Makefile |7 -
> board/samsung/origen/lowlevel_init.S | 397 -
> board/samsung/origen/mem_setup.S | 421 --
> board/samsung/origen/mmc_boot.c| 58 ---
> board/samsung/origen/origen.c | 46 ++
> board/samsung/smdk5250/Makefile|9 -
> board/samsung/smdk5250/lowlevel_init.S |2 +
> board/samsung/smdkv310/Makefile| 10 +-
> board/samsung/smdkv310/lowlevel_init.S | 470
>
> board/samsung/smdkv310/mem_setup.S | 365 ---
> board/samsung/smdkv310/mmc_boot.c | 60 ---
> board/samsung/smdkv310/smdkv310.c | 44 ++
> include/configs/exynos5250-dt.h| 14 +-
> include/configs/origen.h | 10 +-
> include/configs/smdkv310.h |9 +-
> spl/Makefile |4 +
> 35 files changed, 921 insertions(+), 1903 deletions(-)
> rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/clock_init.h
> (100%)
> create mode 100644 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c
> rename board/samsung/smdk5250/clock_init.c =>
> arch/arm/cpu/armv7/exynos/clock_init_exynos5.c (97%)
> create mode 100644 arch/arm/cpu/armv7/exynos/common_setup.h
> rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/dmc_common.c
> (97%)
> rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/dmc_init_ddr3.c
> (96%)
> create mode 100644 arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c
> rename board/samsung/origen/origen_setup.h =>
> arch/arm/cpu/armv7/exynos/exynos4_setup.h (89%)
> rename board/samsung/smdk5250/setup.h =>
> arch/arm/cpu/armv7/exynos/exynos5_setup.h (93%)
> create mode 100644 arch/arm/cpu/armv7/exynos/lowlevel_init.c
> rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/spl_boot.c (61%)
> rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/tzpc_init.c
> (81%)
> rename board/samsung/{smdk5250/smdk5250-uboot-spl.lds =>
> common/exynos-uboot-spl.lds} (100%)
> delete mode 100644 board/samsung/origen/lowlevel_init.S
> delete mode 100644 board/samsung/origen/mem_setup.S
> delete mode 100644 board/samsung/origen/mmc_boot.c
> delete mode 100644 board/samsung/smdkv310/lowlevel_init.S
> delete mode 100644 board/samsung/smdkv310/mem_setup.S
> delete mode 100644 board/samsung/smdkv310/mmc_boot.c
>
> --
> 1.7.4.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
--
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question: issues for usb keyboard work with OHCI HCD
Hi All,
Now, I test usb host support with Atmel boards, for example,
at91sam9x5ek board.
When test OHCI USB host with usb keyboard. I meet the following issue.
--->8---
U-Boot 2013.04-dirty (May 03 2013 - 11:00:34)
CPU: AT91SAM9G35
Crystal frequency: 12 MHz
CPU clock: 400 MHz
Master clock : 133.333 MHz
DRAM: 128 MiB
WARNING: Caches not enabled
NAND: 256 MiB
MMC: mci: 0
In:serial
Out: serial
Err: serial
Net: macb0
Hit any key to stop autoboot: 0
U-Boot> usb start
(Re)start USB...
USB0: scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
U-Boot> setenv stdin usbkbd
U-Boot> ERROR: sohci_submit_job: ENOMEM
ERROR: sohci_submit_job failed
... ...
(repeat to print these two error line)
---<8---
After dig the usb ohci-hcd.c driver, I found every time it call
submit_int_msg -->
submit_common_msg --> sohci_submit_job, it will allocate memory for td
(just call td_alloc),
however nowhere free the td. So, after allocate 64 times (#define NUM_TD
64),
all the ptd[i].usb_dev is not NULL. So, it will report: ENOMEM.
I don't know why in sohci_return_job it call td_submit_job again?
--->8---
static inline int sohci_return_job(struct ohci *hc, urb_priv_t *urb)
{
struct ohci_regs *regs = hc->regs;
switch (usb_pipetype(urb->pipe)) {
case PIPE_INTERRUPT:
/* implicitly requeued */
if (urb->dev->irq_handle &&
(urb->dev->irq_act_len = urb->actual_length)) {
ohci_writel(OHCI_INTR_WDH, ®s->intrenable);
ohci_readl(®s->intrenable); /* PCI posting flush */
urb->dev->irq_handle(urb->dev);
ohci_writel(OHCI_INTR_WDH, ®s->intrdisable);
ohci_readl(®s->intrdisable); /* PCI posting flush */
}
urb->actual_length = 0;
td_submit_job(
urb->dev,
urb->pipe,
urb->transfer_buffer,
urb->transfer_buffer_length,
NULL,
urb,
urb->interval);
break
---<8---
Add where should we free the allocated td to fix the issue?
Thanks.
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] mx23evk: Fix DDR pin iomux settings
Dear Fabio Estevam,
> On Thu, May 2, 2013 at 11:37 PM, Marek Vasut wrote:
> > Uh, why is it even set ? Does the bootrom screw up with it? But then it's
> > cool, just fix those few remaining ramblings of mine and stick my Acks
> > on it.
>
> Ok, let's go step by step.
>
> mx23 reference manual says that EMI pins voltage bits can be:
> 0 - for normal operation
> 1 - invalid.
>
> After reset this bit is 1 and the iomux driver needs to clear this bit.
>
> Let's look at the defines:
>
> #define MXS_PAD_1V8 ((PAD_1V8 << MXS_PAD_VOL_SHIFT) | \
> MXS_PAD_VOL_VALID_MASK)
> #define MXS_PAD_3V3 ((PAD_3V3 << MXS_PAD_VOL_SHIFT) | \
> MXS_PAD_VOL_VALID_MASK)
>
> and then in the iomux;c driver:
>
> if (PAD_VOL_VALID(pad)) {
> bp = PAD_PIN(pad) % 8 * 4 + 2;
> mxs_reg = (struct mxs_register_32 *)(iomux_base + ofs);
> if (PAD_VOL(pad))
> writel(1 << bp, &mxs_reg->reg_set);
> else
> writel(1 << bp, &mxs_reg->reg_clr);
> }
>
> So the only way that the iomux driver can clear the voltage bit is if
> PAD_VOL_VALID(pad) is true, and the only way that PAD_VOL_VALID(pad)
> can be true is if either MXS_PAD_3V3 or MXS_PAD_1V8 are defined, since
> they have the MXS_PAD_VOL_VALID_MASK bit in their definitions.
Yuck. But then, why not configure the pins as 1V8 ? But either way WFM.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] mx23evk: Fix DDR pin iomux settings
On Thu, May 2, 2013 at 11:37 PM, Marek Vasut wrote:
> Uh, why is it even set ? Does the bootrom screw up with it? But then it's
> cool,
> just fix those few remaining ramblings of mine and stick my Acks on it.
Ok, let's go step by step.
mx23 reference manual says that EMI pins voltage bits can be:
0 - for normal operation
1 - invalid.
After reset this bit is 1 and the iomux driver needs to clear this bit.
Let's look at the defines:
#define MXS_PAD_1V8 ((PAD_1V8 << MXS_PAD_VOL_SHIFT) | \
MXS_PAD_VOL_VALID_MASK)
#define MXS_PAD_3V3 ((PAD_3V3 << MXS_PAD_VOL_SHIFT) | \
MXS_PAD_VOL_VALID_MASK)
and then in the iomux;c driver:
if (PAD_VOL_VALID(pad)) {
bp = PAD_PIN(pad) % 8 * 4 + 2;
mxs_reg = (struct mxs_register_32 *)(iomux_base + ofs);
if (PAD_VOL(pad))
writel(1 << bp, &mxs_reg->reg_set);
else
writel(1 << bp, &mxs_reg->reg_clr);
}
So the only way that the iomux driver can clear the voltage bit is if
PAD_VOL_VALID(pad) is true, and the only way that PAD_VOL_VALID(pad)
can be true is if either MXS_PAD_3V3 or MXS_PAD_1V8 are defined, since
they have the MXS_PAD_VOL_VALID_MASK bit in their definitions.
If it is still not clear, just let me know.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] mxs: spl_mem_init: Remove erroneous DDR setting
Dear Fabio Estevam, > On Thu, May 2, 2013 at 11:25 PM, Marek Vasut wrote: > > Is there no such similar bit indicating the init completed? > > Not that I am aware of. That's a tad stupid, but I'll trust you on that. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] mx23evk: Fix DDR pin iomux settings
On Thu, May 2, 2013 at 11:24 PM, Marek Vasut wrote: >> #define MUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP) >> -#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP) >> +#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP) > > btw. if 3V3 setting doesn't exist, why do we have it here? We should just can > it > then. It exists and it is 0. We need to have MXS_PAD_3V3 here, so that the pin voltage bit can be cleared. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Benoît Thébaudeau, > Legacy iomux support is no longer needed now that all boards have been > converted to iomux-v3. > > Signed-off-by: Benoît Thébaudeau Yes, good move Reviewed-by: Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] mxs: spl_mem_init: Remove erroneous DDR setting
On Thu, May 2, 2013 at 11:25 PM, Marek Vasut wrote: > Is there no such similar bit indicating the init completed? Not that I am aware of. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] mx23evk: Fix DDR pin iomux settings
Dear Fabio Estevam, > On Thu, May 2, 2013 at 11:24 PM, Marek Vasut wrote: > >> #define MUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | > >> MXS_PAD_PULLUP) > >> > >> -#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | > >> MXS_PAD_PULLUP) +#define MUX_CONFIG_EMI (MXS_PAD_3V3 | > >> MXS_PAD_12MA | MXS_PAD_PULLUP) > > > > btw. if 3V3 setting doesn't exist, why do we have it here? We should just > > can it then. > > It exists and it is 0. > > We need to have MXS_PAD_3V3 here, so that the pin voltage bit can be > cleared. Uh, why is it even set ? Does the bootrom screw up with it? But then it's cool, just fix those few remaining ramblings of mine and stick my Acks on it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] mx23: Fix pad voltage selection bit
On Thu, May 2, 2013 at 11:24 PM, Marek Vasut wrote: > Acked-by: Marek Vasut > > but then, should we not just undefine this PAD_3V3 for MX23 altogether so > noone > is tempted to use it? No, the EMI pins need to pass MXS_PAD_3V3 to tell the iomux driver that the voltage select value is 0. If we don't do that then it will remain on its reset value, which is 1, and marked as invalid in the reference manual. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] mx23: Fix pad voltage selection bit
Dear Otavio Salvador, > On Thu, May 2, 2013 at 11:24 PM, Marek Vasut wrote: > > Dear Fabio Estevam, > > > >> From: Fabio Estevam > >> > >> On mx23 the pad voltage selection bit needs to be always '0', since '1' > >> is a reserved value. > >> > >> For example: > >> > >> Pin 108, EMI_A06 pin voltage selection: > >> 0= 1.8V (mDDR) or 2.5V (DDR1); > >> 1= reserved. > >> > >> Fix the pad voltage definitions for the mx23 case. > >> > >> Signed-off-by: Fabio Estevam > > > > Acked-by: Marek Vasut > > > > but then, should we not just undefine this PAD_3V3 for MX23 altogether so > > noone is tempted to use it? > > I think for code readability it'd be good to have it in place. It > makes it more obvious for people looking at code. I can already see the people wondering why that piece has no effect ... Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/7] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
On Thu, May 2, 2013 at 11:26 PM, Marek Vasut wrote:
> Dear Fabio Estevam,
>
>> From: Fabio Estevam
>>
>> HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
>> FSL bootlets code.
>>
>> mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as "reserved".
>>
>> HW_DRAM_CTL8 is setup as the last element.
>>
>> So skip the initialization of these DRAM_CTL registers.
>>
>> Signed-off-by: Fabio Estevam
>> ---
>> Changes since v2:
>> - None
>> Changes since v1:
>> - To avoid polluting the mx28 case, separate the function definition in
>> mx23 and for mx28.
>>
>> arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 16 ++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
>> b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index df25535..bf58058 100644
>> --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
>> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
>> @@ -110,6 +110,7 @@ __weak void mxs_adjust_memory_params(uint32_t
>> *dram_vals) {
>> }
>>
>> +#ifdef CONFIG_MX28
>> static void initialize_dram_values(void)
>> {
>> int i;
>> @@ -118,15 +119,26 @@ static void initialize_dram_values(void)
>>
>> for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
>> writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
>> +}
>> +#else
>> +static void initialize_dram_values(void)
>> +{
>> + int i;
>> +
>> + mxs_adjust_memory_params(dram_vals);
>> +
>> + for (i = 0; i < ARRAY_SIZE(dram_vals); i++) {
>> + if (!(i == 8 || i == 27 || i == 28 || i == 35))
>
> if (foo || bar || baz)
> continue;
> writel();
>
> This will be much more readable.
I agree here :)
>> + writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
>> + }
>>
>> -#ifdef CONFIG_MX23
>> /*
>>* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
>>* element to be set
>>*/
>> writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
>> -#endif
>> }
>> +#endif
>>
>> static void mxs_mem_init_clock(void)
>> {
>
> Best regards,
> Marek Vasut
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] mx23: Fix pad voltage selection bit
On Thu, May 2, 2013 at 11:24 PM, Marek Vasut wrote: > Dear Fabio Estevam, > >> From: Fabio Estevam >> >> On mx23 the pad voltage selection bit needs to be always '0', since '1' is >> a reserved value. >> >> For example: >> >> Pin 108, EMI_A06 pin voltage selection: >> 0= 1.8V (mDDR) or 2.5V (DDR1); >> 1= reserved. >> >> Fix the pad voltage definitions for the mx23 case. >> >> Signed-off-by: Fabio Estevam > > Acked-by: Marek Vasut > > but then, should we not just undefine this PAD_3V3 for MX23 altogether so > noone > is tempted to use it? I think for code readability it'd be good to have it in place. It makes it more obvious for people looking at code. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 3/9] DWMMC: Initialise dwmci and resolve EMMC read write issues
Acked-by: Jaehoon Chung
On 04/27/2013 03:12 PM, amar_g wrote:
> From: Amar
>
> This patch enumerates dwmci and set auto stop command during
> dwmci initialisation.
> EMMC read/write is not happening in current implementation
> due to improper fifo size computation. Hence modified the fifo size
> computation to resolve EMMC read write issues.
>
> Signed-off-by: Amar
> ---
> Changes since V1:
> 1)Created the macros RX_WMARK_SHIFT and RX_WMARK_MASK in header file.
>
> 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).
>
> Changes since V4:
> 1)Updated the function dwmci_send_cmd() to use get_timer() instead
> of using mdelay(1).
>
> Changes since V5:
> 1)Updated in response to review comments.
>
> Changes since V6:
> No change.
>
> Changes since V7:
> 1)Updated the function dwmci_setup_bus() to return 0 if (freq == 0).
> This is to avoid the run time exception "raise:Signal # 8 caught".
>
> Changes since V8:
> 1)Auto stop command is disabled, as this feature is not required.
>
> ---
> drivers/mmc/dw_mmc.c | 21 -
> 1 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 4070d4e..1307b12 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -129,13 +129,13 @@ static int dwmci_send_cmd(struct mmc *mmc, struct
> mmc_cmd *cmd,
> unsigned int timeout = 10;
> u32 retry = 1;
> u32 mask, ctrl;
> + ulong start = get_timer(0);
>
> while (dwmci_readl(host, DWMCI_STATUS) & DWMCI_BUSY) {
> - if (timeout == 0) {
> + if (get_timer(start) > timeout) {
> printf("Timeout on data busy\n");
> return TIMEOUT;
> }
> - timeout--;
> }
>
> dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_ALL);
> @@ -143,7 +143,6 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> if (data)
> dwmci_prepare_data(host, data);
>
> -
> dwmci_writel(host, DWMCI_CMDARG, cmd->cmdarg);
>
> if (data)
> @@ -231,9 +230,8 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32
> freq)
> int timeout = 1;
> unsigned long sclk;
>
> - if (freq == host->clock)
> + if ((freq == host->clock) || (freq == 0))
> return 0;
> -
> /*
>* If host->mmc_clk didn't define,
>* then assume that host->bus_hz is source clock value.
> @@ -323,6 +321,9 @@ static int dwmci_init(struct mmc *mmc)
> return -1;
> }
>
> + /* Enumerate at 400KHz */
> + dwmci_setup_bus(host, mmc->f_min);
> +
> dwmci_writel(host, DWMCI_RINTSTS, 0x);
> dwmci_writel(host, DWMCI_INTMASK, 0);
>
> @@ -332,11 +333,13 @@ static int dwmci_init(struct mmc *mmc)
> dwmci_writel(host, DWMCI_BMOD, 1);
>
> fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
> - if (host->fifoth_val)
> + fifo_size = ((fifo_size & RX_WMARK_MASK) >> RX_WMARK_SHIFT) + 1;
> + if (host->fifoth_val) {
> fifoth_val = host->fifoth_val;
> - else
> - fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
> - TX_WMARK(fifo_size/2);
> + } else {
> + fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size / 2 - 1) |
> + TX_WMARK(fifo_size / 2);
> + }
> dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
>
> dwmci_writel(host, DWMCI_CLKENA, 0);
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression from v2013.04-rc3 with sdcard detection
On 05/03/2013 02:53 AM, Stephen Warren wrote: > On 04/21/2013 11:29 AM, Nicolas Chauvet wrote: >> Hi, >> >> I'm experiencing a regression from v2013.04-rc3 that I found related to the >> following commit: >> >> 64f4a6192f0670de2d9af98900b750a3e7bf8ce6 >> 1741c64d642a95c4bb88a2b03e96c6dc7ed5fe62 >> >> With v2013.04 release, when trying to boot from sdcard, I have: >> "Card did not respond to voltage select" >> while detecting the sdcard as mmc 1 Well, i didn't think it is related with that commit. Those patches is just checking revision. And That message is produced that card didn't complete the power-up processing. As Stephen said, which card do you use? If you give more information to us, it is helpful. Best Regards, Jaehoon Chung >> >> Without theses commit or with v2013.04-rc3 >> **File not found /boot.scr.uimg *** >> .and then it find /boot.src on the sdcard. >> >> This was experienced on the Toshiba AC100, aka paz00 using a tegra20 arm >> chipset. > > I can't reproduce this problem with either v2013.04 or the latest > u-boot/master (971020c "sandbox: config: Enable CONFIG_FIT and > CONFIG_CMD_FIT"). Perhaps it depends on the specs of the SD card you > use; what are yours? > > Also, you didn't Cc anyone involved in Tegra, MMC, or the patches you're > reporting problems with. I have added them to this message. Most likely, > nobody saw your email. I only happened to since I returned from > vacation, and searched my list folder for any mention of Tegra. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/7] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
Dear Fabio Estevam,
> From: Fabio Estevam
>
> HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
> FSL bootlets code.
>
> mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as "reserved".
>
> HW_DRAM_CTL8 is setup as the last element.
>
> So skip the initialization of these DRAM_CTL registers.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v2:
> - None
> Changes since v1:
> - To avoid polluting the mx28 case, separate the function definition in
> mx23 and for mx28.
>
> arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index df25535..bf58058 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> @@ -110,6 +110,7 @@ __weak void mxs_adjust_memory_params(uint32_t
> *dram_vals) {
> }
>
> +#ifdef CONFIG_MX28
> static void initialize_dram_values(void)
> {
> int i;
> @@ -118,15 +119,26 @@ static void initialize_dram_values(void)
>
> for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
> writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
> +}
> +#else
> +static void initialize_dram_values(void)
> +{
> + int i;
> +
> + mxs_adjust_memory_params(dram_vals);
> +
> + for (i = 0; i < ARRAY_SIZE(dram_vals); i++) {
> + if (!(i == 8 || i == 27 || i == 28 || i == 35))
if (foo || bar || baz)
continue;
writel();
This will be much more readable.
> + writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
> + }
>
> -#ifdef CONFIG_MX23
> /*
>* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
>* element to be set
>*/
> writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
> -#endif
> }
> +#endif
>
> static void mxs_mem_init_clock(void)
> {
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] mxs: spl_mem_init: Remove erroneous DDR setting
Dear Fabio Estevam, > From: Fabio Estevam > > On mx23 there is no 'DRAM init complete' in register HW_DRAM_CTL18. > > Remove this erroneous setting. > > Signed-off-by: Fabio Estevam > --- > Changes since v2: > - None > Changes since v1: > - Newly introduced as the previous patch is now splitted. > > arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |4 > 1 file changed, 4 deletions(-) > > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c > b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 300da0a..df25535 100644 > --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c > +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c > @@ -279,10 +279,6 @@ static void mx23_mem_init(void) > > setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 19); > setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 11); > - > - /* Wait for bit 10 (DRAM init complete) in DRAM_CTL18 */ > - while (!(readl(MXS_DRAM_BASE + 0x48) & (1 << 10))) > - ; Is there no such similar bit indicating the init completed? > } > #endif Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] mx23evk: Fix DDR pin iomux settings
Dear Fabio Estevam, > From: Fabio Estevam > > Change MUX_CONFIG_EMI to use the same drive strength as the bootlets code > from Freescale, which results in much better stability. > > Signed-off-by: Fabio Estevam > --- > Changes since v2: > - Only change the drive strength > Changes since v1: > - Only adjust MUX_CONFIG_EMI > > board/freescale/mx23evk/spl_boot.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/board/freescale/mx23evk/spl_boot.c > b/board/freescale/mx23evk/spl_boot.c index b6f4e7e..fd6b3d9 100644 > --- a/board/freescale/mx23evk/spl_boot.c > +++ b/board/freescale/mx23evk/spl_boot.c > @@ -26,7 +26,7 @@ > #include > > #define MUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP) > -#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP) > +#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP) btw. if 3V3 setting doesn't exist, why do we have it here? We should just can it then. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] mx23: Fix pad voltage selection bit
Dear Fabio Estevam, > From: Fabio Estevam > > On mx23 the pad voltage selection bit needs to be always '0', since '1' is > a reserved value. > > For example: > > Pin 108, EMI_A06 pin voltage selection: > 0= 1.8V (mDDR) or 2.5V (DDR1); > 1= reserved. > > Fix the pad voltage definitions for the mx23 case. > > Signed-off-by: Fabio Estevam Acked-by: Marek Vasut but then, should we not just undefine this PAD_3V3 for MX23 altogether so noone is tempted to use it? > --- > Changes since v2: > - Only place PAD_3V3 inside the if/else block > Changes since v1: > - Newly introduced > > arch/arm/include/asm/arch-mxs/iomux.h |4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/include/asm/arch-mxs/iomux.h > b/arch/arm/include/asm/arch-mxs/iomux.h index 4288715..f46895e 100644 > --- a/arch/arm/include/asm/arch-mxs/iomux.h > +++ b/arch/arm/include/asm/arch-mxs/iomux.h > @@ -71,7 +71,11 @@ typedef u32 iomux_cfg_t; > #define PAD_16MA 3 > > #define PAD_1V8 0 > +#if defined CONFIG_MX28 > #define PAD_3V3 1 > +#else > +#define PAD_3V3 0 > +#endif > > #define PAD_NOPULL 0 > #define PAD_PULLUP 1 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] mx23: Make DDR initialization stable
Dear Fabio Estevam, > Prior to this series running 'memtester' utility in Linux on a mx23evk > always resulted in many errors during stress testing, if the kernel is > loaded via U-boot. > > Running the same test and loading the kernel via FSL bootlets resulted on > zero errors. > > Adjust U-boot so that it can also pass the 'memtester' stress test. > > After this series was applied, no more DDR errors were observed on a > mx23evk. PATCH v3 0/9 ? ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] EXYNOS: SPI: Support SPI_PREAMBLE mode
On Thu, Mar 21, 2013 at 11:29 PM, Rajeshwari Shinde
wrote:
> Support interfaces with a preamble before each received message.
>
> We handle this when the client has requested a SPI_XFER_END, meaning
> that we must close of the transaction. In this case we read until we
> see the preamble (or a timeout occurs), skipping all data before and
> including the preamble. The client will receive only data bytes after
> the preamble.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Rajeshwari Shinde
> ---
> drivers/spi/exynos_spi.c | 62
> --
> 1 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
> index be60ada..09e88d5 100644
> --- a/drivers/spi/exynos_spi.c
> +++ b/drivers/spi/exynos_spi.c
> @@ -51,6 +51,7 @@ struct exynos_spi_slave {
> unsigned int mode;
> enum periph_id periph_id; /* Peripheral ID for this device */
> unsigned int fifo_size;
> + int skip_preamble;
> };
>
> static struct spi_bus *spi_get_bus(unsigned dev_index)
> @@ -107,6 +108,8 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
> unsigned int cs,
> else
> spi_slave->fifo_size = 256;
>
> + spi_slave->skip_preamble = 0;
> +
> spi_slave->freq = bus->frequency;
> if (max_hz)
> spi_slave->freq = min(max_hz, spi_slave->freq);
> @@ -219,17 +222,23 @@ static void spi_request_bytes(struct exynos_spi *regs,
> int count)
> writel(count | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
> }
>
> -static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
> - void **dinp, void const **doutp)
> +static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
> + void **dinp, void const **doutp, unsigned long flags)
> {
> struct exynos_spi *regs = spi_slave->regs;
> uchar *rxp = *dinp;
> const uchar *txp = *doutp;
> int rx_lvl, tx_lvl;
> uint out_bytes, in_bytes;
> + int toread, preamable_count = 0;
preamable_count: the name is misspelled, and the variable is never modified.
> + unsigned start = get_timer(0);
> + int stopping;
>
> out_bytes = in_bytes = todo;
>
> + stopping = spi_slave->skip_preamble && (flags & SPI_XFER_END) &&
> + !(spi_slave->mode & SPI_SLAVE);
> +
> /*
> * If there's something to send, do a software reset and set a
> * transaction size.
> @@ -240,6 +249,7 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave,
> int todo,
> * Bytes are transmitted/received in pairs. Wait to receive all the
> * data because then transmission will be done as well.
> */
> + toread = in_bytes;
> while (in_bytes) {
> int temp;
>
> @@ -252,13 +262,41 @@ static void spi_rx_tx(struct exynos_spi_slave
> *spi_slave, int todo,
> }
> if (rx_lvl > 0 && in_bytes) {
> temp = readl(®s->rx_data);
> - if (rxp)
> + if (!rxp && !stopping) {
> + in_bytes--;
> + } else if (spi_slave->skip_preamble) {
> + if (temp == SPI_PREAMBLE_END_BYTE) {
> + spi_slave->skip_preamble = 0;
> + stopping = 0;
> + }
> + } else {
> *rxp++ = temp;
> - in_bytes--;
> + in_bytes--;
> + }
> + toread--;
> + }
> + /*
> +* We have run out of input data, but haven't read enough
> +* bytes after the preamble yet. Read some more, and make
> +* sure that we transmit dummy bytes too, to keep things
> +* going.
> +*/
> + else if (in_bytes && !toread) {
> + assert(!out_bytes);
> + toread = out_bytes = in_bytes;
> + txp = NULL;
> + spi_request_bytes(regs, toread);
> + }
> + if (spi_slave->skip_preamble && get_timer(start) > 100) {
> + printf("SPI timeout: in_bytes=%d, out_bytes=%d, ",
> + in_bytes, out_bytes);
> + printf("count = %d\n", preamable_count);
> + return -1;
> }
> }
> *dinp = rxp;
> *doutp = txp;
> + return 0;
> }
>
> /**
> @@ -278,6 +316,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> bitlen, const void *dout,
> struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);
> int upto, todo;
> int
[U-Boot] [PATCH 2/2] buildman: Produce a sensible error message when branch is missing
Rather than a backtrace, produce a nice error message when an invalid
branch is provided to buildman.
Signed-off-by: Simon Glass
---
tools/buildman/control.py | 4
tools/patman/gitutil.py | 21 +++--
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 1ce8b6f..85a4a34 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -111,6 +111,10 @@ def DoBuildman(options, args):
print col.Color(col.RED, str)
sys.exit(1)
count = gitutil.CountCommitsInBranch(options.git_dir, options.branch)
+if count is None:
+str = "Branch '%s' not found or has no upstream" % options.branch
+print col.Color(col.RED, str)
+sys.exit(1)
count += 1 # Build upstream commit also
if not count:
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index e31da15..b7f6739 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -56,10 +56,14 @@ def GetUpstream(git_dir, branch):
Returns:
Name of upstream branch (e.g. 'upstream/master') or None if none
"""
-remote = command.OutputOneLine('git', '--git-dir', git_dir, 'config',
-'branch.%s.remote' % branch)
-merge = command.OutputOneLine('git', '--git-dir', git_dir, 'config',
-'branch.%s.merge' % branch)
+try:
+remote = command.OutputOneLine('git', '--git-dir', git_dir, 'config',
+ 'branch.%s.remote' % branch)
+merge = command.OutputOneLine('git', '--git-dir', git_dir, 'config',
+ 'branch.%s.merge' % branch)
+except:
+return None
+
if remote == '.':
return merge
elif remote and merge:
@@ -78,9 +82,11 @@ def GetRangeInBranch(git_dir, branch,
include_upstream=False):
branch: Name of branch
Return:
Expression in the form 'upstream..branch' which can be used to
-access the commits.
+access the commits. If the branch does not exist, returns None.
"""
upstream = GetUpstream(git_dir, branch)
+if not upstream:
+return None
return '%s%s..%s' % (upstream, '~' if include_upstream else '', branch)
def CountCommitsInBranch(git_dir, branch, include_upstream=False):
@@ -90,9 +96,12 @@ def CountCommitsInBranch(git_dir, branch,
include_upstream=False):
git_dir: Directory containing git repo
branch: Name of branch
Return:
-Number of patches that exist on top of the branch
+Number of patches that exist on top of the branch, or None if the
+branch does not exist.
"""
range_expr = GetRangeInBranch(git_dir, branch, include_upstream)
+if not range_expr:
+return None
pipe = [['git', '--git-dir', git_dir, 'log', '--oneline', '--no-decorate',
range_expr],
['wc', '-l']]
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] buildman: Allow conflicting tags to avoid spurious errors
Conflicting tags can prevent buildman from building two series which exist
one after the other in a branch. There is no reason not to allow this sort
of workflow with buildman, so ignore conflicting tags in buildman.
Signed-off-by: Simon Glass
---
tools/buildman/control.py | 5 +
tools/patman/series.py| 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 8d7b9b5..1ce8b6f 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -137,6 +137,11 @@ def DoBuildman(options, args):
upstream_commit = gitutil.GetUpstream(options.git_dir, options.branch)
series = patchstream.GetMetaDataForList(upstream_commit, options.git_dir,
1)
+# Conflicting tags are not a problem for buildman, since it does not use
+# then. For example, Series-version is not useful for buildman. On the
+# other hand conflicting tags will cause an error. So allow later tags
+# to overwrite earlier ones.
+series.allow_overwrite = True
series = patchstream.GetMetaDataForList(range_expr, options.git_dir, None,
series)
diff --git a/tools/patman/series.py b/tools/patman/series.py
index 783b3dd..85ed316 100644
--- a/tools/patman/series.py
+++ b/tools/patman/series.py
@@ -40,6 +40,7 @@ class Series(dict):
notes: List of lines in the notes
changes: (dict) List of changes for each version, The key is
the integer version number
+allow_overwrite: Allow tags to overwrite an existing tag
"""
def __init__(self):
self.cc = []
@@ -49,6 +50,7 @@ class Series(dict):
self.cover = None
self.notes = []
self.changes = {}
+self.allow_overwrite = False
# Written in MakeCcFile()
# key: name of patch file
@@ -72,7 +74,7 @@ class Series(dict):
"""
# If we already have it, then add to our list
name = name.replace('-', '_')
-if name in self:
+if name in self and not self.allow_overwrite:
values = value.split(',')
values = [str.strip() for str in values]
if type(self[name]) != type([]):
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx.git
The following changes since commit 63216de13488e8bc81afb53d0f5177142ee34ceb: omap5_uevm: Enable redundant MMC environment (2013-05-01 16:41:10 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to 9e186857c7f99600808b8ecb2fc0fa2adeddebaa: powerpc/85xx: set USB2 default mode to 'device' for (super)hydra boards (2013-05-02 16:57:34 -0500) Apologies for the long absense. I got buried in large amounts of work. This is not all of the outstanding 85xx patches, but I intend to now switch and apply a bunch of my MMC backlog. Cristian Sovaiala (1): powerpc/mpc85xx: Changed LIODN offset values dongsheng.w...@freescale.com (1): powerpc/mpc85xx: add setting of clock-frequency for mpic node Horst Kronstorfer (1): mpc85xx: Fix a compiler warning when CONFIG_WATCHDOG is turned on Jeffrey Ladouceur (1): powerpc/mpc85xx: Add revision properties in portal device tree node 'pme' Jiang Bin (1): board/freescale/common/cds_pci_ft.c: Fix rotate wrong cells in interrupt-map property Liu Gang (2): powerpc/b4: Fix the wrong register offset of B4 PCIE module powerpc/b4860qds: Add the tlb entries for SRIO interfaces Matthew McClintock (1): powerpc/p1022ds: Add support for NAND and NAND boot using SPL Poonam Aggrwal (1): doc/ramboot.mpc85xx: Documented the RAMBOOT for MPC85xx Prabhakar Kushwaha (1): powerpc/mpc85xx:IFC Errata A003399 is not valid for BSC913x Shaohui Xie (1): powerpc/85xx: set USB2 default mode to 'device' for (super)hydra boards Shengzhou Liu (3): powerpc/b4860: Adding workaround errata A-005871 powerpc/p1010rdb: Change flexcan compatible string powerpc/p1010rdb: add readme document for p1010rdb Tang Yuantian (1): powerpc/mpc85xx: set clock-frequency for T4/B4 clockgen node Timur Tabi (1): powerpc/85xx: add SerDes bank 4 lanes Xu Jiucheng (1): powerpc/p1_p2_rdb_pc: Add a pin to reset the DDR chip for P1021RDB-PC Xulei (1): powerpc/85xx: Add workaround for errata USB-14 (enable on P204x/P3041/P50x0) York Sun (1): powerpc/mpc85xx: Extend workaround for erratum DDR_A003 to other SoCs Zang Roy-R61911 (1): fman/mEMAC: set SETSP bit in IF_MODE regisgter for RGMII speed Zhicheng Fan (1): qoriq/p1_p2_rdb_pc: USB device-tree fixups for P1020 arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 + arch/powerpc/cpu/mpc85xx/cpu.c| 18 ++- arch/powerpc/cpu/mpc85xx/cpu_init.c | 14 ++ arch/powerpc/cpu/mpc85xx/fdt.c|7 + arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |4 + arch/powerpc/cpu/mpc85xx/p2041_ids.c | 20 +-- arch/powerpc/cpu/mpc85xx/p3041_ids.c | 20 +-- arch/powerpc/cpu/mpc85xx/p5020_ids.c | 20 +-- arch/powerpc/cpu/mpc85xx/portals.c| 20 ++- arch/powerpc/include/asm/config_mpc85xx.h | 12 +- arch/powerpc/include/asm/fsl_memac.h |4 + arch/powerpc/include/asm/immap_85xx.h | 12 +- board/freescale/b4860qds/tlb.c| 19 ++- board/freescale/common/Makefile |6 + board/freescale/common/cds_pci_ft.c | 26 +++- board/freescale/p1010rdb/p1010rdb.c |2 +- board/freescale/p1022ds/Makefile | 14 ++ board/freescale/p1022ds/law.c |1 + board/freescale/p1022ds/spl_minimal.c | 129 board/freescale/p1022ds/tlb.c | 20 ++- board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 66 +++- board/freescale/p1_p2_rdb_pc/spl_minimal.c| 15 ++ boards.cfg|2 + doc/README.p1010rdb | 199 + doc/README.ramboot-ppc85xx| 102 + drivers/net/fm/memac.c| 17 +++ include/configs/P1022DS.h | 132 ++-- include/configs/corenet_ds.h |1 + 28 files changed, 833 insertions(+), 72 deletions(-) create mode 100644 board/freescale/p1022ds/spl_minimal.c create mode 100644 doc/README.p1010rdb create mode 100644 doc/README.ramboot-ppc85xx ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
From: Fabio Estevam
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as "reserved".
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- None
Changes since v1:
- To avoid polluting the mx28 case, separate the function definition in mx23 and
for mx28.
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index df25535..bf58058 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -110,6 +110,7 @@ __weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
}
+#ifdef CONFIG_MX28
static void initialize_dram_values(void)
{
int i;
@@ -118,15 +119,26 @@ static void initialize_dram_values(void)
for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+}
+#else
+static void initialize_dram_values(void)
+{
+ int i;
+
+ mxs_adjust_memory_params(dram_vals);
+
+ for (i = 0; i < ARRAY_SIZE(dram_vals); i++) {
+ if (!(i == 8 || i == 27 || i == 28 || i == 35))
+ writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+ }
-#ifdef CONFIG_MX23
/*
* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
* element to be set
*/
writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
-#endif
}
+#endif
static void mxs_mem_init_clock(void)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] mx23evk: Fix DDR pin iomux settings
From: Fabio Estevam
Change MUX_CONFIG_EMI to use the same drive strength as the bootlets code from
Freescale, which results in much better stability.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Only change the drive strength
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/freescale/mx23evk/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index b6f4e7e..fd6b3d9 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -26,7 +26,7 @@
#include
#defineMUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 7/7] mxs: spl_mem_init: Change EMI port priority
From: Fabio Estevam FSL bootlets code set the PORT_PRIORITY_ORDER field of register HW_EMI_CTRL as 0x2, which means: PORT0231 = 0x02 Priority Order: AXI0, AHB2, AHB3, AHB1 Signed-off-by: Fabio Estevam --- Changes since v2: - None Changes since v1: - None arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index bf58058..5d881da 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -286,7 +286,7 @@ static void mx23_mem_init(void) early_delay(2); /* Adjust EMI port priority. */ - clrsetbits_le32(0x8002, 0x1f << 16, 0x8); + clrsetbits_le32(0x8002, 0x1f << 16, 0x2); early_delay(2); setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 19); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/7] mxs: spl_mem_init: Remove erroneous DDR setting
From: Fabio Estevam On mx23 there is no 'DRAM init complete' in register HW_DRAM_CTL18. Remove this erroneous setting. Signed-off-by: Fabio Estevam --- Changes since v2: - None Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |4 1 file changed, 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 300da0a..df25535 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -279,10 +279,6 @@ static void mx23_mem_init(void) setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 19); setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 11); - - /* Wait for bit 10 (DRAM init complete) in DRAM_CTL18 */ - while (!(readl(MXS_DRAM_BASE + 0x48) & (1 << 10))) - ; } #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 v3 4/7] mxs: spl_mem_init: Fix comment about start bit
From: Fabio Estevam Start bit is part of HW_DRAM_CTL8 register, so fix the comment. Signed-off-by: Fabio Estevam --- Changes since v2: - None Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 4950490..300da0a 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -267,7 +267,7 @@ static void mx23_mem_init(void) initialize_dram_values(); - /* Set START bit in DRAM_CTL16 */ + /* Set START bit in DRAM_CTL8 */ setbits_le32(MXS_DRAM_BASE + 0x20, 1 << 16); clrbits_le32(MXS_DRAM_BASE + 0x40, 1 << 17); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] mx23_olinuxino: Fix DDR pin iomux settings
From: Fabio Estevam
Change MUX_CONFIG_EMI to use the same drive strength as the bootlets code from
Freescale, which results in much better stability.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Only change the drive strength
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/olimex/mx23_olinuxino/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index a96c293..e55947f 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -29,7 +29,7 @@
#include
#include
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_SSP (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/7] mx23: Fix pad voltage selection bit
From: Fabio Estevam On mx23 the pad voltage selection bit needs to be always '0', since '1' is a reserved value. For example: Pin 108, EMI_A06 pin voltage selection: 0= 1.8V (mDDR) or 2.5V (DDR1); 1= reserved. Fix the pad voltage definitions for the mx23 case. Signed-off-by: Fabio Estevam --- Changes since v2: - Only place PAD_3V3 inside the if/else block Changes since v1: - Newly introduced arch/arm/include/asm/arch-mxs/iomux.h |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 4288715..f46895e 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -71,7 +71,11 @@ typedef u32 iomux_cfg_t; #define PAD_16MA 3 #define PAD_1V80 +#if defined CONFIG_MX28 #define PAD_3V31 +#else +#define PAD_3V30 +#endif #define PAD_NOPULL 0 #define PAD_PULLUP 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/9] mx23: Make DDR initialization stable
Prior to this series running 'memtester' utility in Linux on a mx23evk always resulted in many errors during stress testing, if the kernel is loaded via U-boot. Running the same test and loading the kernel via FSL bootlets resulted on zero errors. Adjust U-boot so that it can also pass the 'memtester' stress test. After this series was applied, no more DDR errors were observed on a mx23evk. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] mxs: Fix PULLUP/NOPULL definitions
Hi Michael, On Thu, May 2, 2013 at 6:45 PM, Michael Heimpold wrote: > Could you please link me to your reference where the reverse > definition comes from? Sorry for the confusion, current code is correct for both mx23 and mx28. I discarded this patch and will send v3 shortly. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/11] arm: add Faraday A36x SoC platform support
On Fri, Apr 26, 2013 at 04:02:29PM +0800, Kuo-Jung Su wrote:
> From: Kuo-Jung Su
>
> To: u-boot@lists.denx.de
> CC: Albert Aribaud
>
> These patches introduce Faraday A36x SoC platform support.
>
> Here are some public documents for your reference.
>
> http://www.faraday-tech.com/html/documentation/index.html
>
> There is also a A369 QEMU emulator available at my github account:
>
> https://github.com/dantesu1218/qemu.git
>
> Here is quick start for QEMU:
>
> 1. Download the QEMU source tree
>
> $ git clone -b qemu-1.3.0 https://github.com/dantesu1218/qemu.git
>
> 2. Build & Install the QEMU:
>
> $ ./configure --target-list=arm-softmmu
> $ make
> $ make install
>
> 3. Launch u-boot with QEMU:
>
> $ qemu-system-arm -M a369 -m 512M -nographic -kernel ~/u-boot-devel/u-boot
>
> Changes for v3:
>- Coding Style cleanup.
> There is still one warnning reported by checkpatch.pl,
> however it's too deep for me to fix it.
> Here is the shapshot for it:
> -
> WARNING: do not add new typedefs
> #9735: FILE: include/lcd.h:258:
> +typedef struct vidinfo {
> -
>- Drop bit fields from c struct.
>- Drop macros for wirtel()/readl(), call them directly.
>- Always insert a blank line between declarations and code.
>- Replace all the infinite wait loop with a timeout.
>- Add '__iomem' to all the declaration of HW register pointers.
>- cmd_boot.c: Make it a separate stand-alone patch.
>- ftspi020: Make it a separate stand-alone patch.
>- dma-mapping.h: Have the global data ptr declared outside functions.
>- dma-mapping.h: Add #if...#else...#endif to dma_free_coherent().
>- MMU/D-Cache: Drop static non-cached region, now we use
> map_physmem()/unmap_physmem() for dynamic mappings.
>- ftmac110: Make a correction to multi-line comment style
>- ftmac110: Use random MAC address while having trouble
> to get one from environment variables.
>- ftmac110: Add comments to timing control registers.
>- ftnandc021: Re-write this driver with ECC enabled and
> correct column address handling for OOB read/write,
> and fixing issused addressed by Scott.
>- a36x_config: No more static global network configurations.
>- a36x_config: Add a common file for the redundant configurations.
I see a few:
/*
* Comment
*/
in various places, and I pointed it out in the net changes, but I also
saw in the SPI block '100' being used as a timeout, rather than defined.
Please give everything a check for magic numbers and direct numbers used
as timeout, rather than a #define.
--
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] [PULL] : Please pull u-boot-mpc5xxx
On Thu, May 02, 2013 at 08:59:41PM +0200, Wolfgang Denk wrote: > Dear Tom, > > The following changes since commit 971020c755e5633c9a8f532356ee1750b38dd86f: > > sandbox: config: Enable CONFIG_FIT and CONFIG_CMD_FIT (2013-05-01 11:17:21 > -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-mpc5xxx.git master > > for you to fetch changes up to 8aa34499727936ede3f85033380720b4a9522aaa: > > mpc5200: a3m071/a4m2k: Miscellaneous updates and fixes (2013-05-02 20:46:08 > +0200) > > > Anatolij Gustschin (1): > mpc512x: remove dead code > > Stefan Roese (3): > mpc5200: a3m071/a4m2k: Enable flash verify option > mpc5200: a3m071/a4m2k: Fix problem with increased global_data struct > mpc5200: a3m071/a4m2k: Miscellaneous updates and fixes > > arch/powerpc/cpu/mpc512x/speed.c | 6 --- > board/a3m071/a3m071.c| 26 +--- > include/common.h | 3 -- > include/configs/a3m071.h | 92 > > 4 files changed, 84 insertions(+), 43 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot UBI support
On 5/1/2013 6:31 AM, Tom Rini wrote: When I specified "ubifsmount ubi0:recovery", it worked perfectly. Would you mind patching doc/README.ubi ? Hmm, looks like that currently does not document the ubifsmount command at all. I'll take a look at it over the weekend and see if I can freshen it up. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] mxs: Fix PULLUP/NOPULL definitions
Hi Fabio, > mx23 does not have the "Set this bit to one to _enable_ the internal > pullup" option. Hm, in the RM for i.MX233, page 1480 and above (http://cache.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf) I can only find definitions like "Set this bit to one to _disable_ the internal pad keeper and _enable_ the internal pull up resistor..." or for EMI pads at bank 3 "Set this bit to one to _disable_ the internal keeper" (without a note about pull ups). Could you please link me to your reference where the reverse definition comes from? Best regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/12] imx: mx53loco: Convert to iomux-v3
There is no change of behavior.
Signed-off-by: Benoît Thébaudeau
---
board/freescale/mx53loco/mx53loco.c | 268 +
board/freescale/mx53loco/mx53loco_video.c | 68
2 files changed, 113 insertions(+), 223 deletions(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 8f39c38..10e9d36 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -24,11 +24,10 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -82,86 +81,51 @@ u32 get_board_rev(void)
return (get_cpu_rev() & ~(0xF << 8)) | (rev & 0xF) << 8;
}
+#define UART_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_DSE_HIGH | \
+PAD_CTL_PUS_100K_UP | PAD_CTL_ODE)
+
static void setup_iomux_uart(void)
{
- /* UART1 RXD */
- mxc_request_iomux(MX53_PIN_CSI0_D11, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D11,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_HYS_ENABLE | PAD_CTL_100K_PU |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
- mxc_iomux_set_input(MX53_UART1_IPP_UART_RXD_MUX_SELECT_INPUT, 0x1);
-
- /* UART1 TXD */
- mxc_request_iomux(MX53_PIN_CSI0_D10, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D10,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_HYS_ENABLE | PAD_CTL_100K_PU |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
+ static const iomux_v3_cfg_t uart_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT11__UART1_RXD_MUX, UART_PAD_CTRL),
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT10__UART1_TXD_MUX, UART_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
}
#ifdef CONFIG_USB_EHCI_MX5
int board_ehci_hcd_init(int port)
{
/* request VBUS power enable pin, GPIO7_8 */
- mxc_request_iomux(MX53_PIN_ATA_DA_2, IOMUX_CONFIG_ALT1);
- gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_ATA_DA_2), 1);
+ imx_iomux_v3_setup_pad(MX53_PAD_PATA_DA_2__GPIO7_8);
+ gpio_direction_output(IMX_GPIO_NR(7, 8), 1);
return 0;
}
#endif
static void setup_iomux_fec(void)
{
- /*FEC_MDIO*/
- mxc_request_iomux(MX53_PIN_FEC_MDIO, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_MDIO,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_22K_PU | PAD_CTL_ODE_OPENDRAIN_ENABLE);
- mxc_iomux_set_input(MX53_FEC_FEC_MDI_SELECT_INPUT, 0x1);
-
- /*FEC_MDC*/
- mxc_request_iomux(MX53_PIN_FEC_MDC, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_MDC, PAD_CTL_DRV_HIGH);
-
- /* FEC RXD1 */
- mxc_request_iomux(MX53_PIN_FEC_RXD1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RXD1,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
- /* FEC RXD0 */
- mxc_request_iomux(MX53_PIN_FEC_RXD0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RXD0,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
-/* FEC TXD1 */
- mxc_request_iomux(MX53_PIN_FEC_TXD1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TXD1, PAD_CTL_DRV_HIGH);
-
- /* FEC TXD0 */
- mxc_request_iomux(MX53_PIN_FEC_TXD0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TXD0, PAD_CTL_DRV_HIGH);
-
- /* FEC TX_EN */
- mxc_request_iomux(MX53_PIN_FEC_TX_EN, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TX_EN, PAD_CTL_DRV_HIGH);
-
- /* FEC TX_CLK */
- mxc_request_iomux(MX53_PIN_FEC_REF_CLK, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_REF_CLK,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
- /* FEC RX_ER */
- mxc_request_iomux(MX53_PIN_FEC_RX_ER, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RX_ER,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
- /* FEC CRS */
- mxc_request_iomux(MX53_PIN_FEC_CRS_DV, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_CRS_DV,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
+ static const iomux_v3_cfg_t fec_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_FEC_MDIO__FEC_MDIO, PAD_CTL_HYS |
+ PAD_CTL_DSE_HIGH | PAD_CTL_PUS_22K_UP | PAD_CTL_ODE),
+ NEW_PAD_CTRL(MX53_PAD_FEC_MDC__FEC_MDC, PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_FEC_RXD1__FEC_RDATA_1,
+ PAD_CTL_HYS | PAD_CTL_PKE),
+
[U-Boot] [PATCH 05/12] imx: vision2: Convert to iomux-v3
There is no change of behavior, except for older silicon revisions for which
support is removed.
Signed-off-by: Benoît Thébaudeau
---
board/ttcontrol/vision2/vision2.c | 585 ++---
1 file changed, 223 insertions(+), 362 deletions(-)
diff --git a/board/ttcontrol/vision2/vision2.c
b/board/ttcontrol/vision2/vision2.c
index a471fec..9cc758a 100644
--- a/board/ttcontrol/vision2/vision2.c
+++ b/board/ttcontrol/vision2/vision2.c
@@ -26,10 +26,9 @@
#include
#include
#include
-#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -68,85 +67,67 @@ void hw_watchdog_reset(void)
int val;
/* toggle watchdog trigger pin */
- val = gpio_get_value(66);
+ val = gpio_get_value(IMX_GPIO_NR(3, 2));
val = val ? 0 : 1;
- gpio_set_value(66, val);
+ gpio_set_value(IMX_GPIO_NR(3, 2), val);
}
#endif
static void init_drive_strength(void)
{
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEDDR, PAD_CTL_DDR_INPUT_CMOS);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEADDR, PAD_CTL_PKE_ENABLE);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRAPKS, PAD_CTL_PUE_KEEPER);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRAPUS, PAD_CTL_100K_PU);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_A1, PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_A0, PAD_CTL_DRV_HIGH);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_A1, PAD_CTL_DRV_HIGH);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_RAS,
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CAS,
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEDDR, PAD_CTL_PKE_ENABLE);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRPKS, PAD_CTL_PUE_KEEPER);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR0, PAD_CTL_HYS_NONE);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR1, PAD_CTL_HYS_NONE);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR2, PAD_CTL_HYS_NONE);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR3, PAD_CTL_HYS_NONE);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B0, PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B1, PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B2, PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B4, PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRPUS, PAD_CTL_100K_PU);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_INMODE1, PAD_CTL_DDR_INPUT_CMOS);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B0, PAD_CTL_DRV_MEDIUM);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B1, PAD_CTL_DRV_MEDIUM);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B2, PAD_CTL_DRV_MEDIUM);
- mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B4, PAD_CTL_DRV_MEDIUM);
-
- /* Setting pad options */
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDWE,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCKE0,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCKE1,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCLK,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS0,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS1,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS2,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS3,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CS0,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CS1,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_DQM0,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_DQM1,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_DQM2,
- PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
- PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
- mxc_iomux_set
[U-Boot] [PATCH 08/12] imx: mx53ard: Convert to iomux-v3
There is no change of behavior.
Signed-off-by: Benoît Thébaudeau
---
board/freescale/mx53ard/mx53ard.c | 327 -
1 file changed, 141 insertions(+), 186 deletions(-)
diff --git a/board/freescale/mx53ard/mx53ard.c
b/board/freescale/mx53ard/mx53ard.c
index 32c4d5f..f953aa9 100644
--- a/board/freescale/mx53ard/mx53ard.c
+++ b/board/freescale/mx53ard/mx53ard.c
@@ -23,11 +23,10 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -61,6 +60,41 @@ void dram_init_banksize(void)
#ifdef CONFIG_NAND_MXC
static void setup_iomux_nand(void)
{
+ static const iomux_v3_cfg_t nand_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0,
+ PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_NANDF_CS1__EMI_NANDF_CS_1,
+ PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0,
+ PAD_CTL_PUS_100K_UP),
+ NEW_PAD_CTRL(MX53_PAD_NANDF_CLE__EMI_NANDF_CLE,
+ PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_NANDF_ALE__EMI_NANDF_ALE,
+ PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B,
+ PAD_CTL_PUS_100K_UP),
+ NEW_PAD_CTRL(MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B,
+ PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B,
+ PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA0__EMI_NAND_WEIM_DA_0,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA1__EMI_NAND_WEIM_DA_1,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA2__EMI_NAND_WEIM_DA_2,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA3__EMI_NAND_WEIM_DA_3,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA4__EMI_NAND_WEIM_DA_4,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA5__EMI_NAND_WEIM_DA_5,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA6__EMI_NAND_WEIM_DA_6,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_EIM_DA7__EMI_NAND_WEIM_DA_7,
+ PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_HIGH),
+ };
+
u32 i, reg;
reg = __raw_readl(M4IF_BASE_ADDR + 0xc);
@@ -72,48 +106,7 @@ static void setup_iomux_nand(void)
__raw_writel(reg, WEIM_BASE_ADDR + i);
}
- mxc_request_iomux(MX53_PIN_NANDF_CS0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_CS0, PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_NANDF_CS1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_CS1, PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_NANDF_RB0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_RB0, PAD_CTL_PKE_ENABLE |
- PAD_CTL_PUE_PULL | PAD_CTL_100K_PU);
- mxc_request_iomux(MX53_PIN_NANDF_CLE, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_CLE, PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_NANDF_ALE, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_ALE, PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_NANDF_WP_B, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_WP_B, PAD_CTL_PKE_ENABLE |
- PAD_CTL_PUE_PULL | PAD_CTL_100K_PU);
- mxc_request_iomux(MX53_PIN_NANDF_RE_B, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_RE_B, PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_NANDF_WE_B, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_NANDF_WE_B, PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_EIM_DA0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_EIM_DA0, PAD_CTL_PKE_ENABLE |
- PAD_CTL_100K_PU | PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_EIM_DA1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_EIM_DA1, PAD_CTL_PKE_ENABLE |
- PAD_CTL_100K_PU | PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_EIM_DA2, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_EIM_DA2, PAD_CTL_PKE_ENABLE |
- PAD_CTL_100K_PU | PAD_CTL_DRV_HIGH);
- mxc_request_iomux(MX53_PIN_EIM_DA3, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_EIM_DA3, PAD_CTL_PKE_ENABLE |
- PAD_CTL_100K_PU | PAD_CT
[U-Boot] [PATCH 09/12] imx: mx53evk: Convert to iomux-v3
There is no change of behavior.
Signed-off-by: Benoît Thébaudeau
---
board/freescale/mx53evk/mx53evk.c | 289 +++--
1 file changed, 83 insertions(+), 206 deletions(-)
diff --git a/board/freescale/mx53evk/mx53evk.c
b/board/freescale/mx53evk/mx53evk.c
index 1273501..c984339 100644
--- a/board/freescale/mx53evk/mx53evk.c
+++ b/board/freescale/mx53evk/mx53evk.c
@@ -23,11 +23,10 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -49,69 +48,42 @@ int dram_init(void)
return 0;
}
+#define UART_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_DSE_HIGH | \
+PAD_CTL_PUS_100K_UP | PAD_CTL_ODE)
+
static void setup_iomux_uart(void)
{
- /* UART1 RXD */
- mxc_request_iomux(MX53_PIN_CSI0_D11, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D11,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_HYS_ENABLE | PAD_CTL_100K_PU |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
- mxc_iomux_set_input(MX53_UART1_IPP_UART_RXD_MUX_SELECT_INPUT, 0x1);
-
- /* UART1 TXD */
- mxc_request_iomux(MX53_PIN_CSI0_D10, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D10,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_HYS_ENABLE | PAD_CTL_100K_PU |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
+ static const iomux_v3_cfg_t uart_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT11__UART1_RXD_MUX, UART_PAD_CTRL),
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT10__UART1_TXD_MUX, UART_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
}
+#define I2C_PAD_CTRL (PAD_CTL_SRE_FAST | PAD_CTL_DSE_HIGH | \
+PAD_CTL_PUS_100K_UP | PAD_CTL_HYS | PAD_CTL_ODE)
+
static void setup_i2c(unsigned int port_number)
{
+ static const iomux_v3_cfg_t i2c1_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT8__I2C1_SDA, I2C_PAD_CTRL),
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT9__I2C1_SCL, I2C_PAD_CTRL),
+ };
+
+ static const iomux_v3_cfg_t i2c2_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_KEY_ROW3__I2C2_SDA, I2C_PAD_CTRL),
+ NEW_PAD_CTRL(MX53_PAD_KEY_COL3__I2C2_SCL, I2C_PAD_CTRL),
+ };
+
switch (port_number) {
case 0:
- /* i2c1 SDA */
- mxc_request_iomux(MX53_PIN_CSI0_D8,
- IOMUX_CONFIG_ALT5 | IOMUX_CONFIG_SION);
- mxc_iomux_set_input(MX53_I2C1_IPP_SDA_IN_SELECT_INPUT,
- INPUT_CTL_PATH0);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D8,
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH |
- PAD_CTL_100K_PU | PAD_CTL_HYS_ENABLE |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
- /* i2c1 SCL */
- mxc_request_iomux(MX53_PIN_CSI0_D9,
- IOMUX_CONFIG_ALT5 | IOMUX_CONFIG_SION);
- mxc_iomux_set_input(MX53_I2C1_IPP_SCL_IN_SELECT_INPUT,
- INPUT_CTL_PATH0);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D9,
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH |
- PAD_CTL_100K_PU | PAD_CTL_HYS_ENABLE |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
+ imx_iomux_v3_setup_multiple_pads(i2c1_pads,
+ ARRAY_SIZE(i2c1_pads));
break;
case 1:
- /* i2c2 SDA */
- mxc_request_iomux(MX53_PIN_KEY_ROW3,
- IOMUX_CONFIG_ALT4 | IOMUX_CONFIG_SION);
- mxc_iomux_set_input(MX53_I2C2_IPP_SDA_IN_SELECT_INPUT,
- INPUT_CTL_PATH0);
- mxc_iomux_set_pad(MX53_PIN_KEY_ROW3,
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH |
- PAD_CTL_100K_PU | PAD_CTL_HYS_ENABLE |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
-
- /* i2c2 SCL */
- mxc_request_iomux(MX53_PIN_KEY_COL3,
- IOMUX_CONFIG_ALT4 | IOMUX_CONFIG_SION);
- mxc_iomux_set_input(MX53_I2C2_IPP_SCL_IN_SELECT_INPUT,
- INPUT_CTL_PATH0);
- mxc_iomux_set_pad(MX53_PIN_KEY_COL3,
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH |
- PAD_CTL_100K_PU | PAD_CTL_HYS_ENABLE |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
+ imx_iomux_v3_setup_mul
[U-Boot] [PATCH 04/12] imx: mx51_efikamx/sb: Convert to iomux-v3
There is no change of behavior, except for older silicon revisions for which
support is removed.
Signed-off-by: Benoît Thébaudeau
---
board/genesi/mx51_efikamx/efikamx-usb.c | 122 +--
1 file changed, 69 insertions(+), 53 deletions(-)
diff --git a/board/genesi/mx51_efikamx/efikamx-usb.c
b/board/genesi/mx51_efikamx/efikamx-usb.c
index cf020c3..cabad70 100644
--- a/board/genesi/mx51_efikamx/efikamx-usb.c
+++ b/board/genesi/mx51_efikamx/efikamx-usb.c
@@ -26,8 +26,7 @@
#include
#include
#include
-#include
-#include
+#include
#include
#include
#include
@@ -35,40 +34,57 @@
#include "../../../drivers/usb/host/ehci.h"
-/* USB pin configuration */
-#define USB_PAD_CONFIG (PAD_CTL_PKE_ENABLE | PAD_CTL_SRE_FAST | \
- PAD_CTL_DRV_HIGH | PAD_CTL_100K_PU | \
- PAD_CTL_HYS_ENABLE | PAD_CTL_PUE_PULL)
-
/*
* Configure the USB H1 and USB H2 IOMUX
*/
void setup_iomux_usb(void)
{
- setup_iomux_usb_h1();
-
- if (machine_is_efikasb())
- setup_iomux_usb_h2();
-
- /* USB PHY reset */
- mxc_request_iomux(MX51_PIN_EIM_D27, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_EIM_D27, PAD_CTL_PKE_ENABLE |
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
-
- /* USB HUB reset */
- mxc_request_iomux(MX51_PIN_GPIO1_5, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_GPIO1_5, PAD_CTL_PKE_ENABLE |
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
-
- /* WIFI EN (act low) */
- mxc_request_iomux(MX51_PIN_EIM_A22, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_A22, 0);
- /* WIFI RESET */
- mxc_request_iomux(MX51_PIN_EIM_A16, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_A16, 0);
- /* BT EN (act low) */
- mxc_request_iomux(MX51_PIN_EIM_A17, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_A17, 0);
+ static const iomux_v3_cfg_t usb_h1_pads[] = {
+ MX51_PAD_USBH1_CLK__USBH1_CLK,
+ MX51_PAD_USBH1_DIR__USBH1_DIR,
+ MX51_PAD_USBH1_STP__USBH1_STP,
+ MX51_PAD_USBH1_NXT__USBH1_NXT,
+ MX51_PAD_USBH1_DATA0__USBH1_DATA0,
+ MX51_PAD_USBH1_DATA1__USBH1_DATA1,
+ MX51_PAD_USBH1_DATA2__USBH1_DATA2,
+ MX51_PAD_USBH1_DATA3__USBH1_DATA3,
+ MX51_PAD_USBH1_DATA4__USBH1_DATA4,
+ MX51_PAD_USBH1_DATA5__USBH1_DATA5,
+ MX51_PAD_USBH1_DATA6__USBH1_DATA6,
+ MX51_PAD_USBH1_DATA7__USBH1_DATA7,
+ };
+
+ static const iomux_v3_cfg_t usb_pads[] = {
+ MX51_PAD_EIM_D27__GPIO2_9, /* USB PHY reset */
+ MX51_PAD_GPIO1_5__GPIO1_5, /* USB HUB reset */
+ NEW_PAD_CTRL(MX51_PAD_EIM_A22__GPIO2_16, 0), /* WIFI /EN */
+ NEW_PAD_CTRL(MX51_PAD_EIM_A16__GPIO2_10, 0), /* WIFI RESET */
+ NEW_PAD_CTRL(MX51_PAD_EIM_A17__GPIO2_11, 0), /* BT /EN */
+ };
+
+ imx_iomux_v3_setup_multiple_pads(usb_h1_pads, ARRAY_SIZE(usb_h1_pads));
+
+ if (machine_is_efikasb()) {
+ static const iomux_v3_cfg_t usb_h2_pads[] = {
+ MX51_PAD_EIM_A24__USBH2_CLK,
+ MX51_PAD_EIM_A25__USBH2_DIR,
+ MX51_PAD_EIM_A26__USBH2_STP,
+ MX51_PAD_EIM_A27__USBH2_NXT,
+ MX51_PAD_EIM_D16__USBH2_DATA0,
+ MX51_PAD_EIM_D17__USBH2_DATA1,
+ MX51_PAD_EIM_D18__USBH2_DATA2,
+ MX51_PAD_EIM_D19__USBH2_DATA3,
+ MX51_PAD_EIM_D20__USBH2_DATA4,
+ MX51_PAD_EIM_D21__USBH2_DATA5,
+ MX51_PAD_EIM_D22__USBH2_DATA6,
+ MX51_PAD_EIM_D23__USBH2_DATA7,
+ };
+
+ imx_iomux_v3_setup_multiple_pads(usb_h2_pads,
+ARRAY_SIZE(usb_h2_pads));
+ }
+
+ imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
}
/*
@@ -77,18 +93,18 @@ void setup_iomux_usb(void)
static void efika_usb_enable_devices(void)
{
/* Enable Bluetooth */
- gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 0);
+ gpio_direction_output(IMX_GPIO_NR(2, 11), 0);
udelay(1);
- gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 1);
+ gpio_set_value(IMX_GPIO_NR(2, 11), 1);
/* Enable WiFi */
- gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A22), 1);
+ gpio_direction_output(IMX_GPIO_NR(2, 16), 1);
udelay(1);
/* Reset the WiFi chip */
- gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A16), 0);
+ gpio_direction_output(IMX_GPIO_NR(2, 10), 0);
udelay(1);
- gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_A16), 1);
+ gpio_set_value(IMX_GPIO_NR(2, 10), 1);
}
/*
@@ -97,11 +113,11 @@ static void efika_u
[U-Boot] [PATCH 11/12] imx: mx53smd: Convert to iomux-v3
There is no change of behavior.
Signed-off-by: Benoît Thébaudeau
---
board/freescale/mx53smd/mx53smd.c | 152 -
1 file changed, 48 insertions(+), 104 deletions(-)
diff --git a/board/freescale/mx53smd/mx53smd.c
b/board/freescale/mx53smd/mx53smd.c
index 761f727..d04f44f 100644
--- a/board/freescale/mx53smd/mx53smd.c
+++ b/board/freescale/mx53smd/mx53smd.c
@@ -23,11 +23,10 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -56,76 +55,41 @@ void dram_init_banksize(void)
gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
}
+#define UART_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_DSE_HIGH | \
+PAD_CTL_PUS_100K_UP | PAD_CTL_ODE)
+
static void setup_iomux_uart(void)
{
- /* UART1 RXD */
- mxc_request_iomux(MX53_PIN_CSI0_D11, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D11,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_HYS_ENABLE | PAD_CTL_100K_PU |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
- mxc_iomux_set_input(MX53_UART1_IPP_UART_RXD_MUX_SELECT_INPUT, 0x1);
-
- /* UART1 TXD */
- mxc_request_iomux(MX53_PIN_CSI0_D10, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D10,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_HYS_ENABLE | PAD_CTL_100K_PU |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
+ static const iomux_v3_cfg_t uart_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT11__UART1_RXD_MUX, UART_PAD_CTRL),
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT10__UART1_TXD_MUX, UART_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
}
static void setup_iomux_fec(void)
{
- /*FEC_MDIO*/
- mxc_request_iomux(MX53_PIN_FEC_MDIO, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_MDIO,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE |
- PAD_CTL_22K_PU | PAD_CTL_ODE_OPENDRAIN_ENABLE);
- mxc_iomux_set_input(MX53_FEC_FEC_MDI_SELECT_INPUT, 0x1);
-
- /*FEC_MDC*/
- mxc_request_iomux(MX53_PIN_FEC_MDC, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_MDC, PAD_CTL_DRV_HIGH);
-
- /* FEC RXD1 */
- mxc_request_iomux(MX53_PIN_FEC_RXD1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RXD1,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
- /* FEC RXD0 */
- mxc_request_iomux(MX53_PIN_FEC_RXD0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RXD0,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
-/* FEC TXD1 */
- mxc_request_iomux(MX53_PIN_FEC_TXD1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TXD1, PAD_CTL_DRV_HIGH);
-
- /* FEC TXD0 */
- mxc_request_iomux(MX53_PIN_FEC_TXD0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TXD0, PAD_CTL_DRV_HIGH);
-
- /* FEC TX_EN */
- mxc_request_iomux(MX53_PIN_FEC_TX_EN, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TX_EN, PAD_CTL_DRV_HIGH);
-
- /* FEC TX_CLK */
- mxc_request_iomux(MX53_PIN_FEC_REF_CLK, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_REF_CLK,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
- /* FEC RX_ER */
- mxc_request_iomux(MX53_PIN_FEC_RX_ER, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RX_ER,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
-
- /* FEC CRS */
- mxc_request_iomux(MX53_PIN_FEC_CRS_DV, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_CRS_DV,
- PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
+ static const iomux_v3_cfg_t fec_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_FEC_MDIO__FEC_MDIO, PAD_CTL_HYS |
+ PAD_CTL_DSE_HIGH | PAD_CTL_PUS_22K_UP | PAD_CTL_ODE),
+ NEW_PAD_CTRL(MX53_PAD_FEC_MDC__FEC_MDC, PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_FEC_RXD1__FEC_RDATA_1,
+ PAD_CTL_HYS | PAD_CTL_PKE),
+ NEW_PAD_CTRL(MX53_PAD_FEC_RXD0__FEC_RDATA_0,
+ PAD_CTL_HYS | PAD_CTL_PKE),
+ NEW_PAD_CTRL(MX53_PAD_FEC_TXD1__FEC_TDATA_1, PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_FEC_TXD0__FEC_TDATA_0, PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_FEC_TX_EN__FEC_TX_EN, PAD_CTL_DSE_HIGH),
+ NEW_PAD_CTRL(MX53_PAD_FEC_REF_CLK__FEC_TX_CLK,
+ PAD_CTL_HYS | PAD_CTL_PKE)
[U-Boot] [PATCH 07/12] imx: ima3-mx53: Convert to iomux-v3
There is no change of behavior.
Signed-off-by: Benoît Thébaudeau
---
board/esg/ima3-mx53/ima3-mx53.c | 227 +--
include/configs/ima3-mx53.h |3 -
2 files changed, 72 insertions(+), 158 deletions(-)
diff --git a/board/esg/ima3-mx53/ima3-mx53.c b/board/esg/ima3-mx53/ima3-mx53.c
index 41d6bb6..d1817fa 100644
--- a/board/esg/ima3-mx53/ima3-mx53.c
+++ b/board/esg/ima3-mx53/ima3-mx53.c
@@ -23,11 +23,10 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -66,109 +65,53 @@ int dram_init(void)
return 0;
}
+#define UART_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_DSE_HIGH | \
+PAD_CTL_PUS_100K_UP | PAD_CTL_ODE)
+
static void setup_iomux_uart(void)
{
- /* UART4 RXD */
- mxc_request_iomux(MX53_PIN_CSI0_D13, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D13,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE | PAD_CTL_HYS_ENABLE |
- PAD_CTL_100K_PU | PAD_CTL_ODE_OPENDRAIN_ENABLE);
- mxc_iomux_set_input(MX53_UART4_IPP_UART_RXD_MUX_SELECT_INPUT, 0x3);
-
- /* UART4 TXD */
- mxc_request_iomux(MX53_PIN_CSI0_D12, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX53_PIN_CSI0_D12,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE | PAD_CTL_HYS_ENABLE |
- PAD_CTL_100K_PU | PAD_CTL_ODE_OPENDRAIN_ENABLE);
+ static const iomux_v3_cfg_t uart_pads[] = {
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT13__UART4_RXD_MUX, UART_PAD_CTRL),
+ NEW_PAD_CTRL(MX53_PAD_CSI0_DAT12__UART4_TXD_MUX, UART_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
}
static void setup_iomux_fec(void)
{
- /*FEC_MDIO*/
- mxc_request_iomux(MX53_PIN_FEC_MDIO, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_MDIO,
- PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
- PAD_CTL_PUE_PULL | PAD_CTL_PKE_ENABLE | PAD_CTL_22K_PU |
- PAD_CTL_ODE_OPENDRAIN_ENABLE);
- mxc_iomux_set_input(MX53_FEC_FEC_MDI_SELECT_INPUT, 0x1);
-
- /*FEC_MDC*/
- mxc_request_iomux(MX53_PIN_FEC_MDC, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_MDC, PAD_CTL_DRV_HIGH);
-
- /* FEC RXD3 */
- mxc_request_iomux(MX53_PIN_KEY_COL0, IOMUX_CONFIG_ALT6);
- mxc_iomux_set_pad(MX53_PIN_KEY_COL0, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC RXD2 */
- mxc_request_iomux(MX53_PIN_KEY_COL2, IOMUX_CONFIG_ALT6);
- mxc_iomux_set_pad(MX53_PIN_KEY_COL2, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC RXD1 */
- mxc_request_iomux(MX53_PIN_FEC_RXD1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RXD1, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC RXD0 */
- mxc_request_iomux(MX53_PIN_FEC_RXD0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RXD0, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC TXD3 */
- mxc_request_iomux(MX53_PIN_GPIO_19, IOMUX_CONFIG_ALT6);
- mxc_iomux_set_pad(MX53_PIN_GPIO_19, PAD_CTL_DRV_HIGH);
-
- /* FEC TXD2 */
- mxc_request_iomux(MX53_PIN_KEY_ROW2, IOMUX_CONFIG_ALT6);
- mxc_iomux_set_pad(MX53_PIN_KEY_ROW2, PAD_CTL_DRV_HIGH);
-
- /* FEC TXD1 */
- mxc_request_iomux(MX53_PIN_FEC_TXD1, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TXD1, PAD_CTL_DRV_HIGH);
-
- /* FEC TXD0 */
- mxc_request_iomux(MX53_PIN_FEC_TXD0, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TXD0, PAD_CTL_DRV_HIGH);
-
- /* FEC TX_EN */
- mxc_request_iomux(MX53_PIN_FEC_TX_EN, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_TX_EN, PAD_CTL_DRV_HIGH);
-
- /* FEC TX_CLK */
- mxc_request_iomux(MX53_PIN_FEC_REF_CLK, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_REF_CLK, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC RX_ER */
- mxc_request_iomux(MX53_PIN_FEC_RX_ER, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_RX_ER, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC RX_DV */
- mxc_request_iomux(MX53_PIN_FEC_CRS_DV, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX53_PIN_FEC_CRS_DV, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC CRS */
- mxc_request_iomux(MX53_PIN_KEY_COL3, IOMUX_CONFIG_ALT6);
- mxc_iomux_set_pad(MX53_PIN_KEY_COL3, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
-
- /* FEC COL */
- mxc_request_iomux(MX53_PIN_KEY_ROW1, IOMUX_CONFIG_ALT6);
- mxc_iomux_set_pad(MX53_PIN_KEY_ROW1, PAD_CTL_HYS_ENABLE |
- PAD_CTL_PKE_ENABLE);
- mxc_iomux_set_input(MX53_FEC_FEC_COL_SELECT_INPUT,
[U-Boot] [PATCH 01/12] imx: iomux-mx51: Fix MX51_PAD_EIM_CS2__GPIO2_27
In ALT1 mode, EIM_CS2 is GPIO2[27], not ESDHC1.CD. Hence, rename
MX51_PAD_EIM_CS2__SD1_CD to MX51_PAD_EIM_CS2__GPIO2_27.
Signed-off-by: Benoît Thébaudeau
---
arch/arm/include/asm/arch-mx5/iomux-mx51.h |2 +-
board/genesi/mx51_efikamx/efikamx.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
index 328c188..323e118 100644
--- a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -61,7 +61,7 @@ enum {
MX51_PAD_EIM_A26__USBH2_STP = IOMUX_PAD(0x458, 0x0c4, 2,
__NA_, 0, NO_PAD_CTRL),
MX51_PAD_EIM_A27__USBH2_NXT = IOMUX_PAD(0x45c, 0x0c8, 2,
__NA_, 0, NO_PAD_CTRL),
MX51_PAD_EIM_CS0__GPIO2_25 = IOMUX_PAD(0x474, 0x0e0, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
- MX51_PAD_EIM_CS2__SD1_CD= IOMUX_PAD(0x47c, 0x0e8, 1,
__NA_, 0, MX51_ESDHC_PAD_CTRL),
+ MX51_PAD_EIM_CS2__GPIO2_27 = IOMUX_PAD(0x47c, 0x0e8, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_EIM_CS3__GPIO2_28 = IOMUX_PAD(0x480, 0x0ec, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_EIM_CS4__GPIO2_29 = IOMUX_PAD(0x484, 0x0f0, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_NANDF_WE_B__PATA_DIOW = IOMUX_PAD(0x4e4, 0x108, 1,
__NA_, 0, NO_PAD_CTRL),
diff --git a/board/genesi/mx51_efikamx/efikamx.c
b/board/genesi/mx51_efikamx/efikamx.c
index 69d41db..13582a2 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -293,7 +293,7 @@ static iomux_v3_cfg_t const efikamx_sdhc1_pads[] = {
static iomux_v3_cfg_t const efikamx_sdhc1_cd_pads[] = {
MX51_PAD_GPIO1_0__SD1_CD,
- MX51_PAD_EIM_CS2__SD1_CD,
+ NEW_PAD_CTRL(MX51_PAD_EIM_CS2__GPIO2_27, MX51_ESDHC_PAD_CTRL),
};
#define EFIKAMX_SDHC1_CD IMX_GPIO_NR(1, 0)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/12] imx: mx51evk: Convert to iomux-v3
There is no change of behavior, except for older silicon revisions for which
support is removed.
Signed-off-by: Benoît Thébaudeau
---
board/freescale/mx51evk/mx51evk.c | 348 +++
board/freescale/mx51evk/mx51evk_video.c | 22 +-
2 files changed, 131 insertions(+), 239 deletions(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 54c16b1..369da6d 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -24,8 +24,7 @@
#include
#include
#include
-#include
-#include
+#include
#include
#include
#include
@@ -64,160 +63,103 @@ u32 get_board_rev(void)
return rev;
}
+#define UART_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_HIGH)
+
static void setup_iomux_uart(void)
{
- unsigned int pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE |
- PAD_CTL_PUE_PULL | PAD_CTL_DRV_HIGH;
-
- mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_RXD, pad | PAD_CTL_SRE_FAST);
- mxc_request_iomux(MX51_PIN_UART1_TXD, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_TXD, pad | PAD_CTL_SRE_FAST);
- mxc_request_iomux(MX51_PIN_UART1_RTS, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_RTS, pad);
- mxc_request_iomux(MX51_PIN_UART1_CTS, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_CTS, pad);
+ static const iomux_v3_cfg_t uart_pads[] = {
+ MX51_PAD_UART1_RXD__UART1_RXD,
+ MX51_PAD_UART1_TXD__UART1_TXD,
+ NEW_PAD_CTRL(MX51_PAD_UART1_RTS__UART1_RTS, UART_PAD_CTRL),
+ NEW_PAD_CTRL(MX51_PAD_UART1_CTS__UART1_CTS, UART_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
}
static void setup_iomux_fec(void)
{
- /*FEC_MDIO*/
- mxc_request_iomux(MX51_PIN_EIM_EB2 , IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_EB2 , 0x1FD);
-
- /*FEC_MDC*/
- mxc_request_iomux(MX51_PIN_NANDF_CS3, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS3, 0x2004);
-
- /* FEC RDATA[3] */
- mxc_request_iomux(MX51_PIN_EIM_CS3, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS3, 0x180);
-
- /* FEC RDATA[2] */
- mxc_request_iomux(MX51_PIN_EIM_CS2, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS2, 0x180);
-
- /* FEC RDATA[1] */
- mxc_request_iomux(MX51_PIN_EIM_EB3, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_EB3, 0x180);
-
- /* FEC RDATA[0] */
- mxc_request_iomux(MX51_PIN_NANDF_D9, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_D9, 0x2180);
-
- /* FEC TDATA[3] */
- mxc_request_iomux(MX51_PIN_NANDF_CS6, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS6, 0x2004);
-
- /* FEC TDATA[2] */
- mxc_request_iomux(MX51_PIN_NANDF_CS5, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS5, 0x2004);
-
- /* FEC TDATA[1] */
- mxc_request_iomux(MX51_PIN_NANDF_CS4, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS4, 0x2004);
-
- /* FEC TDATA[0] */
- mxc_request_iomux(MX51_PIN_NANDF_D8, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_D8, 0x2004);
-
- /* FEC TX_EN */
- mxc_request_iomux(MX51_PIN_NANDF_CS7, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS7, 0x2004);
-
- /* FEC TX_ER */
- mxc_request_iomux(MX51_PIN_NANDF_CS2, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS2, 0x2004);
-
- /* FEC TX_CLK */
- mxc_request_iomux(MX51_PIN_NANDF_RDY_INT, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_RDY_INT, 0x2180);
-
- /* FEC TX_COL */
- mxc_request_iomux(MX51_PIN_NANDF_RB2, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_RB2, 0x2180);
-
- /* FEC RX_CLK */
- mxc_request_iomux(MX51_PIN_NANDF_RB3, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_RB3, 0x2180);
-
- /* FEC RX_CRS */
- mxc_request_iomux(MX51_PIN_EIM_CS5, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS5, 0x180);
-
- /* FEC RX_ER */
- mxc_request_iomux(MX51_PIN_EIM_CS4, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS4, 0x180);
-
- /* FEC RX_DV */
- mxc_request_iomux(MX51_PIN_NANDF_D11, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_D11, 0x2180);
+ static const iomux_v3_cfg_t fec_pads[] = {
+ NEW_PAD_CTRL(MX51_PAD_EIM_EB2__FEC_MDIO, PAD_CTL_HYS |
+ PAD_CTL_PUS_22K_UP | PAD_CTL_ODE |
+ PAD_CTL_DSE_HIGH | PAD_CTL_SRE_FAST),
+ MX51_PAD_NANDF_CS3__FEC_MDC,
+ NEW_PAD_CTRL(MX51_PAD_EIM_CS3__FEC_RDATA3, MX51_PAD_CTRL_2),
+ NEW_PAD_CTRL(MX51_PAD_EIM_CS2__FEC_RDATA2, MX51_PAD_CTRL_2),
+
[U-Boot] [PATCH 02/12] imx: iomux-v3: Add missing definitions to iomux-mx51.h
Add missing definitions that are required by future changes.
By the way, make some cosmetic cleanup.
Signed-off-by: Benoît Thébaudeau
---
arch/arm/include/asm/arch-mx5/iomux-mx51.h | 151 +++-
1 file changed, 124 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
index 323e118..70aaa37 100644
--- a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -22,7 +22,7 @@
#include
/* Pad control groupings */
-#define MX51_UART_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_DSE_HIGH | \
+#define MX51_UART_PAD_CTRL (PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_HIGH | \
PAD_CTL_HYS | PAD_CTL_SRE_FAST)
#define MX51_I2C_PAD_CTRL (PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
@@ -30,7 +30,7 @@
#define MX51_ESDHC_PAD_CTRL(PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
PAD_CTL_HYS)
-#define MX51_USBH1_PAD_CTRL(PAD_CTL_SRE_FAST | PAD_CTL_DSE_HIGH | \
+#define MX51_USBH_PAD_CTRL (PAD_CTL_SRE_FAST | PAD_CTL_DSE_HIGH | \
PAD_CTL_PUS_100K_UP | PAD_CTL_HYS)
#define MX51_ECSPI_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_HYS | \
PAD_CTL_DSE_HIGH | PAD_CTL_SRE_FAST)
@@ -38,32 +38,67 @@
PAD_CTL_SRE_FAST | PAD_CTL_DVS)
#define MX51_GPIO_PAD_CTRL (PAD_CTL_DSE_HIGH | PAD_CTL_PKE |
PAD_CTL_SRE_FAST)
+#define MX51_PAD_CTRL_2(PAD_CTL_PKE | PAD_CTL_HYS)
+#define MX51_PAD_CTRL_4(PAD_CTL_PKE | PAD_CTL_DVS |
PAD_CTL_HYS)
+#define MX51_PAD_CTRL_5(PAD_CTL_DVS | PAD_CTL_DSE_HIGH)
+
/*
* The naming convention for the pad modes is MX51_PAD___
* If or refers to a GPIO, it is named GPIO_
* See also iomux-v3.h
*/
-/* PADMUX
ALT INPSE PATH PADCTRL */
+/* PADMUX ALT
INPSE PATH PADCTRL */
enum {
- MX51_PAD_EIM_D16__USBH2_DATA0 = IOMUX_PAD(0x3f0, 0x05c, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D17__USBH2_DATA1 = IOMUX_PAD(0x3f4, 0x060, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D18__USBH2_DATA2 = IOMUX_PAD(0x3f8, 0x064, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D19__USBH2_DATA3 = IOMUX_PAD(0x3fc, 0x068, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D20__USBH2_DATA4 = IOMUX_PAD(0x400, 0x06c, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D21__USBH2_DATA5 = IOMUX_PAD(0x404, 0x070, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D22__USBH2_DATA6 = IOMUX_PAD(0x408, 0x074, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D23__USBH2_DATA7 = IOMUX_PAD(0x40c, 0x078, 2,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_EIM_D16__USBH2_DATA0 = IOMUX_PAD(0x3f0, 0x05c, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D17__GPIO2_1 = IOMUX_PAD(0x3f4, 0x060, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_D17__USBH2_DATA1 = IOMUX_PAD(0x3f4, 0x060, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D18__USBH2_DATA2 = IOMUX_PAD(0x3f8, 0x064, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D19__USBH2_DATA3 = IOMUX_PAD(0x3fc, 0x068, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D20__USBH2_DATA4 = IOMUX_PAD(0x400, 0x06c, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D21__GPIO2_5 = IOMUX_PAD(0x404, 0x070, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_D21__USBH2_DATA5 = IOMUX_PAD(0x404, 0x070, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D22__USBH2_DATA6 = IOMUX_PAD(0x408, 0x074, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D23__USBH2_DATA7 = IOMUX_PAD(0x40c, 0x078, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D25__UART3_RXD = IOMUX_PAD(0x414, 0x080, 3,
0x9f4, 0, MX51_UART_PAD_CTRL),
+ MX51_PAD_EIM_D26__UART3_TXD = IOMUX_PAD(0x418, 0x084, 3,
__NA_, 0, MX51_UART_PAD_CTRL),
MX51_PAD_EIM_D27__GPIO2_9 = IOMUX_PAD(0x41c, 0x088, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
- MX51_PAD_EIM_A24__USBH2_CLK = IOMUX_PAD(0x450, 0x0bc, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_A25__USBH2_DIR = IOMUX_PAD(0x454, 0x0c0, 2,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_EIM_A16__GPIO2_10 = IOMUX_PAD(0x430, 0x09c, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_A17__GPIO2_11 = IOMUX_PAD(0x434, 0x0a0, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_A20__GPIO2_14 = IOMUX_PAD(0x440, 0x0ac, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD
[U-Boot] [PATCH v2 6/6] imx: mx25: Remove legacy iomux support
Legacy iomux support is no longer needed now that all boards have been converted
to iomux-v3.
Signed-off-by: Benoît Thébaudeau
---
Changes in v2: None
arch/arm/cpu/arm926ejs/mx25/generic.c | 117 ---
arch/arm/include/asm/arch-mx25/imx25-pinmux.h | 421 -
arch/arm/include/asm/arch-mx25/sys_proto.h| 32 --
3 files changed, 570 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-mx25/imx25-pinmux.h
delete mode 100644 arch/arm/include/asm/arch-mx25/sys_proto.h
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index 679273b..7cbbe65 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
#ifdef CONFIG_FSL_ESDHC
@@ -248,123 +247,7 @@ int cpu_mmc_init(bd_t *bis)
}
#endif
-#ifdef CONFIG_MXC_UART
-void mx25_uart1_init_pins(void)
-{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 inpadctl;
- u32 outpadctl;
- u32 muxmode0;
-
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
- muxmode0 = MX25_PIN_MUX_MODE(0);
- /*
-* set up input pins with hysteresis and 100K pull-ups
-*/
- inpadctl = MX25_PIN_PAD_CTL_HYS
- | MX25_PIN_PAD_CTL_PKE
- | MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PU;
-
- /*
-* set up output pins with 100K pull-downs
-* FIXME: need to revisit this
-* PUE is ignored if PKE is not set
-* so the right value here is likely
-*0x0 for no pull up/down
-* or
-*0xc0 for 100k pull down
-*/
- outpadctl = MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PD;
-
- /* UART1 */
- /* rxd */
- writel(muxmode0, &muxctl->pad_uart1_rxd);
- writel(inpadctl, &padctl->pad_uart1_rxd);
-
- /* txd */
- writel(muxmode0, &muxctl->pad_uart1_txd);
- writel(outpadctl, &padctl->pad_uart1_txd);
-
- /* rts */
- writel(muxmode0, &muxctl->pad_uart1_rts);
- writel(outpadctl, &padctl->pad_uart1_rts);
-
- /* cts */
- writel(muxmode0, &muxctl->pad_uart1_cts);
- writel(inpadctl, &padctl->pad_uart1_cts);
-}
-#endif /* CONFIG_MXC_UART */
-
#ifdef CONFIG_FEC_MXC
-void mx25_fec_init_pins(void)
-{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 inpadctl_100kpd;
- u32 inpadctl_22kpu;
- u32 outpadctl;
- u32 muxmode0;
-
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
- muxmode0 = MX25_PIN_MUX_MODE(0);
- inpadctl_100kpd = MX25_PIN_PAD_CTL_HYS
- | MX25_PIN_PAD_CTL_PKE
- | MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PD;
- inpadctl_22kpu = MX25_PIN_PAD_CTL_HYS
- | MX25_PIN_PAD_CTL_PKE
- | MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_22K_PU;
- /*
-* set up output pins with 100K pull-downs
-* FIXME: need to revisit this
-* PUE is ignored if PKE is not set
-* so the right value here is likely
-*0x0 for no pull
-* or
-*0xc0 for 100k pull down
-*/
- outpadctl = MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PD;
-
- /* FEC_TX_CLK */
- writel(muxmode0, &muxctl->pad_fec_tx_clk);
- writel(inpadctl_100kpd, &padctl->pad_fec_tx_clk);
-
- /* FEC_RX_DV */
- writel(muxmode0, &muxctl->pad_fec_rx_dv);
- writel(inpadctl_100kpd, &padctl->pad_fec_rx_dv);
-
- /* FEC_RDATA0 */
- writel(muxmode0, &muxctl->pad_fec_rdata0);
- writel(inpadctl_100kpd, &padctl->pad_fec_rdata0);
-
- /* FEC_TDATA0 */
- writel(muxmode0, &muxctl->pad_fec_tdata0);
- writel(outpadctl, &padctl->pad_fec_tdata0);
-
- /* FEC_TX_EN */
- writel(muxmode0, &muxctl->pad_fec_tx_en);
- writel(outpadctl, &padctl->pad_fec_tx_en);
-
- /* FEC_MDC */
- writel(muxmode0, &muxctl->pad_fec_mdc);
- writel(outpadctl, &padctl->pad_fec_mdc);
-
- /* FEC_MDIO */
- writel(muxmode0, &muxctl->pad_fec_mdio);
- writel(inpadctl_22kpu, &padctl->pad_fec_mdio);
-
- /* FEC_RDATA1 */
- writel(muxmode0, &muxctl->pad_fec_rdata1);
- writel(inpadctl_100kpd, &padctl->pad_fec_rdata1);
-
- /* FEC_TDATA1 */
- writel(muxmode0, &muxctl->pad_fec_tdata1);
- writel(outpadctl, &padctl->pad_fec_tdata1);
-
-}
-
void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
{
int i;
diff --git a/arch/arm/include/asm/arch-mx25/imx25-pinmux.h
b/arch/arm/include/asm/arch-mx25/imx25-pinmux.h
deleted file mode 100644
index a4c658b..000
--- a/arch/arm/include/asm/arch-mx25/imx25-pinmux.h
+++ /dev/null
@@ -1,421 +0,0 @@
-/*
- * iopin settings
[U-Boot] [PATCH v2 2/6] imx: mx25pdk: Convert to iomux-v3
There is no change of behavior, even if some pad control values could probably
be simplified.
Signed-off-by: Benoît Thébaudeau
---
Changes in v2: None
board/freescale/mx25pdk/mx25pdk.c | 128 ++---
1 file changed, 75 insertions(+), 53 deletions(-)
diff --git a/board/freescale/mx25pdk/mx25pdk.c
b/board/freescale/mx25pdk/mx25pdk.c
index d73e27e..421afea 100644
--- a/board/freescale/mx25pdk/mx25pdk.c
+++ b/board/freescale/mx25pdk/mx25pdk.c
@@ -21,8 +21,7 @@
#include
#include
#include
-#include
-#include
+#include
#include
#include
#include
@@ -43,29 +42,42 @@ struct fsl_esdhc_cfg esdhc_cfg[1] = {
};
#endif
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define FEC_OUT_PAD_CTRL 0
+
+#define I2C_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP | \
+PAD_CTL_ODE)
+
static void mx25pdk_fec_init(void)
{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
- u32 gpio_mux_mode0_sion = MX25_PIN_MUX_MODE(0) | MX25_PIN_MUX_SION;
-
- /* FEC pin init is generic */
- mx25_fec_init_pins();
-
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
- /*
-* Set up FEC_RESET_B and FEC_ENABLE_B
-*
-* FEC_RESET_B: gpio2_3 is ALT 5 mode of pin D12
-* FEC_ENABLE_B: gpio4_8 is ALT 5 mode of pin A17
-*/
- writel(gpio_mux_mode, &muxctl->pad_d12);
- writel(gpio_mux_mode, &muxctl->pad_a17);
-
- writel(0x0, &padctl->pad_d12);
- writel(0x0, &padctl->pad_a17);
+ static const iomux_v3_cfg_t fec_pads[] = {
+ MX25_PAD_FEC_TX_CLK__FEC_TX_CLK,
+ MX25_PAD_FEC_RX_DV__FEC_RX_DV,
+ MX25_PAD_FEC_RDATA0__FEC_RDATA0,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA0__FEC_TDATA0, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_TX_EN__FEC_TX_EN, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_MDC__FEC_MDC, FEC_OUT_PAD_CTRL),
+ MX25_PAD_FEC_MDIO__FEC_MDIO,
+ MX25_PAD_FEC_RDATA1__FEC_RDATA1,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA1__FEC_TDATA1, FEC_OUT_PAD_CTRL),
+
+ NEW_PAD_CTRL(MX25_PAD_D12__GPIO_4_8, 0), /* FEC_RESET_B */
+ NEW_PAD_CTRL(MX25_PAD_A17__GPIO_2_3, 0), /* FEC_ENABLE_B */
+ };
+
+ static const iomux_v3_cfg_t i2c_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_I2C1_CLK__I2C1_CLK, I2C_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_I2C1_DAT__I2C1_DAT, I2C_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
/* Assert RESET and ENABLE low */
gpio_direction_output(FEC_RESET_B, 0);
@@ -78,10 +90,7 @@ static void mx25pdk_fec_init(void)
gpio_set_value(FEC_ENABLE_B, 1);
/* Setup I2C pins so that PMIC can turn on PHY supply */
- writel(gpio_mux_mode0_sion, &muxctl->pad_i2c1_clk);
- writel(gpio_mux_mode0_sion, &muxctl->pad_i2c1_dat);
- writel(0x1E8, &padctl->pad_i2c1_clk);
- writel(0x1E8, &padctl->pad_i2c1_dat);
+ imx_iomux_v3_setup_multiple_pads(i2c_pads, ARRAY_SIZE(i2c_pads));
}
int dram_init(void)
@@ -92,9 +101,35 @@ int dram_init(void)
return 0;
}
+/*
+ * Set up input pins with hysteresis and 100-k pull-ups
+ */
+#define UART1_IN_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP)
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define UART1_OUT_PAD_CTRL 0
+
+static void mx25pdk_uart1_init(void)
+{
+ static const iomux_v3_cfg_t uart1_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_UART1_RXD__UART1_RXD, UART1_IN_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_UART1_TXD__UART1_TXD, UART1_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_UART1_RTS__UART1_RTS, UART1_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_UART1_CTS__UART1_CTS, UART1_IN_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
+}
+
int board_early_init_f(void)
{
- mx25_uart1_init_pins();
+ mx25pdk_uart1_init();
return 0;
}
@@ -131,21 +166,8 @@ int board_late_init(void)
#ifdef CONFIG_FSL_ESDHC
int board_mmc_getcd(struct mmc *mmc)
{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
-
- /*
-* Set up the Card Detect pin.
-*
-* SD1_GPIO_CD: gpio2_1 is ALT 5 mode of pin A15
-*
-*/
- muxctl = (struct iomuxc_mux_ctl *)
[U-Boot] [PATCH v2 4/6] imx: tx25: Convert to iomux-v3
There is no change of behavior, even if some pad control values could probably
be simplified.
Signed-off-by: Benoît Thébaudeau
---
Changes in v2: None
board/karo/tx25/tx25.c | 107 ++--
1 file changed, 68 insertions(+), 39 deletions(-)
diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 85719a0..2952eba 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -27,9 +27,8 @@
#include
#include
#include
-#include
+#include
#include
-#include
DECLARE_GLOBAL_DATA_PTR;
@@ -42,36 +41,44 @@ void board_init_f(ulong bootflag)
#endif
#ifdef CONFIG_FEC_MXC
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define FEC_OUT_PAD_CTRL 0
+
#define GPIO_FEC_RESET_B IMX_GPIO_NR(4, 7)
#define GPIO_FEC_ENABLE_B IMX_GPIO_NR(4, 9)
void tx25_fec_init(void)
{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
- u32 saved_rdata0_mode, saved_rdata1_mode, saved_rx_dv_mode;
+ static const iomux_v3_cfg_t fec_pads[] = {
+ MX25_PAD_FEC_TX_CLK__FEC_TX_CLK,
+ MX25_PAD_FEC_RX_DV__FEC_RX_DV,
+ MX25_PAD_FEC_RDATA0__FEC_RDATA0,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA0__FEC_TDATA0, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_TX_EN__FEC_TX_EN, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_MDC__FEC_MDC, FEC_OUT_PAD_CTRL),
+ MX25_PAD_FEC_MDIO__FEC_MDIO,
+ MX25_PAD_FEC_RDATA1__FEC_RDATA1,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA1__FEC_TDATA1, FEC_OUT_PAD_CTRL),
+
+ NEW_PAD_CTRL(MX25_PAD_D13__GPIO_4_7, 0), /* FEC_RESET_B */
+ NEW_PAD_CTRL(MX25_PAD_D11__GPIO_4_9, 0), /* FEC_ENABLE_B */
+ };
+
+ static const iomux_v3_cfg_t fec_cfg_pads[] = {
+ MX25_PAD_FEC_RDATA0__GPIO_3_10,
+ MX25_PAD_FEC_RDATA1__GPIO_3_11,
+ MX25_PAD_FEC_RX_DV__GPIO_3_12,
+ };
debug("tx25_fec_init\n");
- /*
-* fec pin init is generic
-*/
- mx25_fec_init_pins();
-
- /*
-* Set up the FEC_RESET_B and FEC_ENABLE GPIO pins.
-*
-* FEC_RESET_B: gpio4[7] is ALT 5 mode of pin D13
-* FEC_ENABLE_B: gpio4[9] is ALT 5 mode of pin D11
-*/
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
-
- writel(gpio_mux_mode, &muxctl->pad_d13);
- writel(gpio_mux_mode, &muxctl->pad_d11);
-
- writel(0x0, &padctl->pad_d13);
- writel(0x0, &padctl->pad_d11);
+ imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
/* drop PHY power and assert reset (low) */
gpio_direction_output(GPIO_FEC_RESET_B, 0);
@@ -99,15 +106,10 @@ void tx25_fec_init(void)
* RMII mode is selected by FEC_RX_DV which is GPIO 3_12 in mux mode
*/
/*
-* save three current mux modes and set each to gpio mode
+* set each mux mode to gpio mode
*/
- saved_rdata0_mode = readl(&muxctl->pad_fec_rdata0);
- saved_rdata1_mode = readl(&muxctl->pad_fec_rdata1);
- saved_rx_dv_mode = readl(&muxctl->pad_fec_rx_dv);
-
- writel(gpio_mux_mode, &muxctl->pad_fec_rdata0);
- writel(gpio_mux_mode, &muxctl->pad_fec_rdata1);
- writel(gpio_mux_mode, &muxctl->pad_fec_rx_dv);
+ imx_iomux_v3_setup_multiple_pads(fec_cfg_pads,
+ ARRAY_SIZE(fec_cfg_pads));
/*
* set each to 1 and make each an output
@@ -128,19 +130,46 @@ void tx25_fec_init(void)
/*
* set FEC pins back
*/
- writel(saved_rdata0_mode, &muxctl->pad_fec_rdata0);
- writel(saved_rdata1_mode, &muxctl->pad_fec_rdata1);
- writel(saved_rx_dv_mode, &muxctl->pad_fec_rx_dv);
+ imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
}
#else
#define tx25_fec_init()
#endif
-int board_init()
-{
#ifdef CONFIG_MXC_UART
- mx25_uart1_init_pins();
+/*
+ * Set up input pins with hysteresis and 100-k pull-ups
+ */
+#define UART1_IN_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP)
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define UART1_OUT_PAD_CTRL 0
+
+static void tx25_uart1_init(void)
+{
+ static const iomux_v3_cfg_t uart1_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_UART1_RXD__UART1_RXD, UART1_IN_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_UART1_TXD__UART1_TXD, UART1_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_
[U-Boot] [PATCH v2 3/6] imx: mx25pdk: Fix GPIO assignments
Signed-off-by: Benoît Thébaudeau --- Changes in v2: None board/freescale/mx25pdk/mx25pdk.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/freescale/mx25pdk/mx25pdk.c b/board/freescale/mx25pdk/mx25pdk.c index 421afea..5e6047f 100644 --- a/board/freescale/mx25pdk/mx25pdk.c +++ b/board/freescale/mx25pdk/mx25pdk.c @@ -30,8 +30,8 @@ #include #include -#define FEC_RESET_BIMX_GPIO_NR(2, 3) -#define FEC_ENABLE_B IMX_GPIO_NR(4, 8) +#define FEC_RESET_BIMX_GPIO_NR(4, 8) +#define FEC_ENABLE_B IMX_GPIO_NR(2, 3) #define CARD_DETECTIMX_GPIO_NR(2, 1) DECLARE_GLOBAL_DATA_PTR; -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] imx: zmx25: Convert to iomux-v3
There is no change of behavior, even if some pad control values could probably
be simplified.
Signed-off-by: Benoît Thébaudeau
---
Changes in v2: None
board/syteco/zmx25/zmx25.c | 143 ++--
1 file changed, 72 insertions(+), 71 deletions(-)
diff --git a/board/syteco/zmx25/zmx25.c b/board/syteco/zmx25/zmx25.c
index 4f37c59..087d856 100644
--- a/board/syteco/zmx25/zmx25.c
+++ b/board/syteco/zmx25/zmx25.c
@@ -32,91 +32,85 @@
#include
#include
#include
-#include
-#include
+#include
DECLARE_GLOBAL_DATA_PTR;
int board_init()
{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- struct iomuxc_pad_input_select *inputselect;
- u32 gpio_mux_mode0_sion = MX25_PIN_MUX_MODE(0) | MX25_PIN_MUX_SION;
- u32 gpio_mux_mode1 = MX25_PIN_MUX_MODE(1);
- u32 gpio_mux_mode5 = MX25_PIN_MUX_MODE(5);
- u32 gpio_mux_mode6 = MX25_PIN_MUX_MODE(6);
- u32 input_select1 = MX25_PAD_INPUT_SELECT_DAISY(1);
- u32 input_select2 = MX25_PAD_INPUT_SELECT_DAISY(2);
+ static const iomux_v3_cfg_t sdhc1_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_SD1_CMD__SD1_CMD, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_SD1_CLK__SD1_CLK, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_SD1_DATA0__SD1_DATA0, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_SD1_DATA1__SD1_DATA1, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_SD1_DATA2__SD1_DATA2, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_SD1_DATA3__SD1_DATA3, NO_PAD_CTRL),
+ };
+
+ static const iomux_v3_cfg_t dig_out_pads[] = {
+ MX25_PAD_CSI_D8__GPIO_1_7, /* Ouput 1 Ctrl */
+ MX25_PAD_CSI_D7__GPIO_1_6, /* Ouput 2 Ctrl */
+ NEW_PAD_CTRL(MX25_PAD_CSI_D6__GPIO_1_31, 0), /* Ouput 1 Stat */
+ NEW_PAD_CTRL(MX25_PAD_CSI_D5__GPIO_1_30, 0), /* Ouput 2 Stat */
+ };
+
+ static const iomux_v3_cfg_t led_pads[] = {
+ MX25_PAD_CSI_D9__GPIO_4_21,
+ MX25_PAD_CSI_D4__GPIO_1_29,
+ };
+
+ static const iomux_v3_cfg_t can_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_GPIO_A__CAN1_TX, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_GPIO_B__CAN1_RX, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_GPIO_C__CAN2_TX, NO_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_GPIO_D__CAN2_RX, NO_PAD_CTRL),
+ };
+
+ static const iomux_v3_cfg_t i2c3_pads[] = {
+ MX25_PAD_CSPI1_SS1__I2C3_DAT,
+ MX25_PAD_GPIO_E__I2C3_CLK,
+ };
icache_enable();
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
- inputselect = (struct iomuxc_pad_input_select *)IMX_IOPADINPUTSEL_BASE;
-
- /* Setup of core volatage selection pin to run at 1.4V */
- writel(gpio_mux_mode5, &muxctl->pad_ext_armclk); /* VCORE GPIO3[15] */
+ /* Setup of core voltage selection pin to run at 1.4V */
+ imx_iomux_v3_setup_pad(MX25_PAD_EXT_ARMCLK__GPIO_3_15); /* VCORE */
gpio_direction_output(IMX_GPIO_NR(3, 15), 1);
- /* Setup of input daisy chains for SD card pins*/
- writel(gpio_mux_mode0_sion, &muxctl->pad_sd1_cmd);
- writel(gpio_mux_mode0_sion, &muxctl->pad_sd1_clk);
- writel(gpio_mux_mode0_sion, &muxctl->pad_sd1_data0);
- writel(gpio_mux_mode0_sion, &muxctl->pad_sd1_data1);
- writel(gpio_mux_mode0_sion, &muxctl->pad_sd1_data2);
- writel(gpio_mux_mode0_sion, &muxctl->pad_sd1_data3);
+ /* Setup of SD card pins*/
+ imx_iomux_v3_setup_multiple_pads(sdhc1_pads, ARRAY_SIZE(sdhc1_pads));
/* Setup of digital output for USB power and OC */
- writel(gpio_mux_mode5, &muxctl->pad_csi_d3); /* USB Power GPIO1[28] */
+ imx_iomux_v3_setup_pad(MX25_PAD_CSI_D3__GPIO_1_28); /* USB Power */
gpio_direction_output(IMX_GPIO_NR(1, 28), 1);
- writel(gpio_mux_mode5, &muxctl->pad_csi_d2); /* USB OC GPIO1[27] */
+ imx_iomux_v3_setup_pad(MX25_PAD_CSI_D2__GPIO_1_27); /* USB OC */
gpio_direction_input(IMX_GPIO_NR(1, 18));
/* Setup of digital output control pins */
- writel(gpio_mux_mode5, &muxctl->pad_csi_d8); /* Ouput 1 Ctrl GPIO1[7] */
- writel(gpio_mux_mode5, &muxctl->pad_csi_d7); /* Ouput 2 Ctrl GPIO1[6] */
- writel(gpio_mux_mode5, &muxctl->pad_csi_d6); /* Ouput 1 Stat GPIO1[31]*/
- writel(gpio_mux_mode5, &muxctl->pad_csi_d5); /* Ouput 2 Stat GPIO1[30]*/
-
- writel(0, &padctl->pad_csi_d6); /* Ouput 1 Stat pull up off */
- writel(0, &padctl->pad_csi_d5); /* Ouput 2 Stat pull up off */
+ imx_iomux_v3_setup_multiple_pads(dig_out_pads,
+ ARRAY_SIZE(dig_out_pads));
/* Switch both output drivers off */
gpio_direction_output(IMX_GPIO_NR(1, 7), 0);
gpio_direction_output(IMX_GPIO_NR(1, 6), 0);
- /* Setup of key input pin GPIO2[29]*/
-
[U-Boot] [PATCH v2 1/6] imx: iomux-v3: Add iomux-mx25.h
Allow usage of the imx-common/iomux-v3.h framework by including pad settings for
the i.MX25. The content of the file is taken from Linux kernel at commit
267dd34, plus the required changes to make it work in U-Boot.
Signed-off-by: Benoît Thébaudeau
---
Changes in v2:
- Fix arch/arm/imx-common/Makefile COBJS-y for mx5/6.
arch/arm/imx-common/Makefile|5 +-
arch/arm/include/asm/arch-mx25/imx-regs.h |1 +
arch/arm/include/asm/arch-mx25/iomux-mx25.h | 545 +++
3 files changed, 550 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-mx25/iomux-mx25.h
diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 9309439..4d2553c 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -27,8 +27,11 @@ include $(TOPDIR)/config.mk
LIB = $(obj)libimx-common.o
+ifeq ($(SOC),$(filter $(SOC),mx25 mx5 mx6))
+COBJS-y= iomux-v3.o
+endif
ifeq ($(SOC),$(filter $(SOC),mx5 mx6))
-COBJS-y= iomux-v3.o timer.o cpu.o speed.o
+COBJS-y+= timer.o cpu.o speed.o
COBJS-$(CONFIG_I2C_MXC) += i2c-mxv7.o
endif
ifeq ($(SOC),$(filter $(SOC),mx6 mxs))
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 206ac76..46f59d7 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -200,6 +200,7 @@ struct aips_regs {
#define IMX_CSPI1_BASE (0x43FA4000)
#define IMX_KPP_BASE (0x43FA8000)
#define IMX_IOPADMUX_BASE (0x43FAC000)
+#define IOMUXC_BASE_ADDR IMX_IOPADMUX_BASE
#define IMX_IOPADCTL_BASE (0x43FAC22C)
#define IMX_IOPADGRPCTL_BASE (0x43FAC418)
#define IMX_IOPADINPUTSEL_BASE (0x43FAC460)
diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
new file mode 100644
index 000..c0f5c61
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
@@ -0,0 +1,545 @@
+/*
+ * (C) Copyright 2013 ADVANSEE
+ * Benoît Thébaudeau
+ *
+ * Based on mainline Linux i.MX iomux-mx25.h file:
+ * Copyright (C) 2009 by Lothar Wassmann
+ *
+ * Based on Linux arch/arm/mach-mx25/mx25_pins.h:
+ * Copyright 2008 Freescale Semiconductor, Inc. All Rights Reserved.
+ * and Linux arch/arm/plat-mxc/include/mach/iomux-mx35.h:
+ * Copyright (C) 2009 by Jan Weitzel Phytec Messtechnik GmbH
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __IOMUX_MX25_H__
+#define __IOMUX_MX25_H__
+
+#include
+
+/* Pad control groupings */
+#define MX25_KPP_ROW_PAD_CTRL PAD_CTL_PUS_100K_UP
+#define MX25_KPP_COL_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_ODE)
+
+/*
+ * The naming convention for the pad modes is MX25_PAD___
+ * If or refers to a GPIO, it is named GPIO__
+ * See also iomux-v3.h
+ */
+
+/* PADMUXALT
INPSE PATH PADCTRL */
+enum {
+ MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008, 0x00,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008, 0x05,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A13__A13 = IOMUX_PAD(0x22C, 0x00c, 0x00,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A13__GPIO_4_1 = IOMUX_PAD(0x22C, 0x00c, 0x05,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A14__A14 = IOMUX_PAD(0x230, 0x010, 0x10,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A14__GPIO_2_0 = IOMUX_PAD(0x230, 0x010, 0x15,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A15__A15 = IOMUX_PAD(0x234, 0x014, 0x10,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A15__GPIO_2_1 = IOMUX_PAD(0x234, 0x014, 0x15,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A16__A16 = IOMUX_PAD(0x000, 0x018, 0x10,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A16__GPIO_2_2 = IOMUX_PAD(0x000, 0x018, 0x15,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A17__A17 = IOMUX_PAD(0x238, 0x01c, 0x10,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A17__GPIO_2_3 = IOMUX_PAD(0x238, 0x01c, 0x15,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A18__A18 = IOMUX_PAD(0x23c, 0x020, 0x1
Re: [U-Boot] [PATCH v2 2/8] mxs: Fix PULLUP/NOPULL definitions
Dear Fabio Estevam, > Hi Michael, > > On Thu, May 2, 2013 at 3:44 PM, Michael Heimpold wrote: > > Sorry, but I think this is not correct. Please have a look > > at the reference manual for i.MX28 page 786: > > It seems that some pins have an internal pullup, but other > > pins "only" have the internal keeper you mentioned. > > > > Quote from : > > bank 0 pin 24: "Set this bit to one to _enable_ the internal pullup..." > > bank 0 pin 25: "Set this bit to one to _disable_ the internal keeper..." > > > > So I think the current implementation is correct. > > Ok, I see. > > mx23 does not have the "Set this bit to one to _enable_ the internal > pullup" option. > > > However, if you are trying to enable a pullup for a pin which does not > > have this function (e.g. because the hardware guys trimmed the BOM > > and did not spend an external pullup) you are actually disabling the > > keeper which makes the situation even worse in some situations. > > > > I'm still wondering what an ideal solution could be... > > So I plan to keep mx28 bits untouched and do the reverse definition > only for mx23: > > #if defined CONFIG_MX28 > #define PAD_PULLUP1 > #define PAD_NOPULL0 > #else > #define PAD_PULLUP0 > #define PAD_NOPULL1 > #endif Wait, this code is pulled from Linux kernel. How does Linux solve that? Is it also broken in Linux? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] mxs: Fix PULLUP/NOPULL definitions
Hi Michael, On Thu, May 2, 2013 at 3:44 PM, Michael Heimpold wrote: > Sorry, but I think this is not correct. Please have a look > at the reference manual for i.MX28 page 786: > It seems that some pins have an internal pullup, but other > pins "only" have the internal keeper you mentioned. > > Quote from : > bank 0 pin 24: "Set this bit to one to _enable_ the internal pullup..." > bank 0 pin 25: "Set this bit to one to _disable_ the internal keeper..." > > So I think the current implementation is correct. Ok, I see. mx23 does not have the "Set this bit to one to _enable_ the internal pullup" option. > > However, if you are trying to enable a pullup for a pin which does not > have this function (e.g. because the hardware guys trimmed the BOM > and did not spend an external pullup) you are actually disabling the > keeper which makes the situation even worse in some situations. > > I'm still wondering what an ideal solution could be... So I plan to keep mx28 bits untouched and do the reverse definition only for mx23: #if defined CONFIG_MX28 #define PAD_PULLUP 1 #define PAD_NOPULL 0 #else #define PAD_PULLUP 0 #define PAD_NOPULL 1 #endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Tegra: Config: Enable Tegra30/Tegra114 USB function
On 04/29/2013 03:21 AM, Jim Lin wrote: > Add USB EHCI, storage and network support. > > Tested on Tegra30 Cardhu, and Tegra114 Dalmore > platforms. All works well. What about updating include/configs/beaver.h too? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
On 04/29/2013 03:21 AM, Jim Lin wrote:
> Tegra30 and Tegra114 are compatible except
> 1. T30 takes 55 ms to finish Port Reset. T114 takes
>50 ms.
Is that 55-vs-50 some aspect of the HW specification itself, or the
overall result of multiple separate delays? I ask because the statement
that one piece of HW differs from another only in a delay, especially
where that delay is enormous in HW terms, seem very unusual.
> diff --git a/arch/arm/include/asm/arch-tegra114/tegra.h
> b/arch/arm/include/asm/arch-tegra114/tegra.h
> +#define TEGRA_USB1_BASE 0x7D00
That shouldn't be needed; if some of the module base addresses come from
DT, then they all should, or there's no point using DT.
> diff --git a/arch/arm/include/asm/arch-tegra114/usb.h
> b/arch/arm/include/asm/arch-tegra114/usb.h
> +#ifndef _TEGRA_USB_H_
> +#define _TEGRA_USB_H_
> +
> +
> +/* USB Controller (USBx_CONTROLLER_) regs */
There's an extra blank line there. The same problem exists elsewhere,
and in the other copies of this file.
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> void ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg)
> {
> - mdelay(50);
> - if (((u32) status_reg & TEGRA_USB_ADDR_MASK) != TEGRA_USB1_BASE)
> + udelay(49990);
> + if (is_T30_compatible) {
The code shouldn't test against a specific chip version, but rather
against some property of the HW (like the length of the delay). That
way, it will be scalable when we support 10 different Tegra versions and
the mapping from version number to feature isn't easy to represent.
> + /*
> + * Tegra 114 takes 50 ms to assert Port Enable bit.
> + * We have to exit earlier. Otherwise ehci-hcd.c will clear
> + * our Port Enable bit.
> + */
> + if (is_T114_compatible)
> + return;
> + /* Tegra 3 takes about 55 ms to assert Port Enable bit. */
> + udelay(5010);
> + return;
> + }
This looks like an enormous hack. What is it doing? Why? Can't all 3
chips simply loop polling until some enable status bit is set?
> + udelay(10);
> + if (((u32)status_reg & TEGRA_USB_ADDR_MASK) != TEGRA_USB1_BASE)
> return;
This also should test against a feature, not the identity of the port.
The DT properties nvidia,has-legacy-mode or nvidia,needs-double-reset
might be relevant here?
> @@ -171,7 +177,7 @@ static void set_host_mode(struct fdt_usb *config)
>* bail out in this case.
>*/
> if (config->dr_mode == DR_MODE_OTG &&
> - (readl(&config->reg->phy_vbus_sensors) & VBUS_VLD_STS))
> + (readl(&config->reg->phy_vbus_sensors) & VBUS_VLD_STS))
That's an unrelated whitespace change. Whitespace cleanup should be in a
separate patch first, so it doesn't clutter functional changes.
> @@ -232,45 +240,112 @@ static int init_utmi_usb_controller(struct fdt_usb
> *config)
>* To Use the A Session Valid for cable detection logic, VBUS_WAKEUP
>* mux must be switched to actually use a_sess_vld threshold.
>*/
> - if (fdt_gpio_isvalid(&config->vbus_gpio)) {
> + if (config->dr_mode == DR_MODE_OTG &&
> + fdt_gpio_isvalid(&config->vbus_gpio))
> clrsetbits_le32(&usbctlr->usb1_legacy_ctrl,
> - VBUS_SENSE_CTL_MASK,
> - VBUS_SENSE_CTL_A_SESS_VLD << VBUS_SENSE_CTL_SHIFT);
> - }
> + VBUS_SENSE_CTL_MASK,
> + VBUS_SENSE_CTL_A_SESS_VLD <<
> + VBUS_SENSE_CTL_SHIFT);
Partially a white-space change. There are many other ws-changes later
that I didn't bother pointing out.
> + timing = (u32 *)config->params;
> + if (is_T30_compatible)
> + goto pll_T30_init;
...
> + goto pll_init_done;
> +
> +pll_T30_init:
...
> +pll_init_done:
Uggh. Use functions.
> @@ -325,17 +409,37 @@ static int init_utmi_usb_controller(struct fdt_usb
> *config)
> /* Disable ICUSB FS/LS transceiver */
> clrbits_le32(&usbctlr->icusb_ctrl, IC_ENB1);
>
> - /* Select UTMI parallel interface */
> - clrsetbits_le32(&usbctlr->port_sc1, PTS_MASK,
> - PTS_UTMI << PTS_SHIFT);
> - clrbits_le32(&usbctlr->port_sc1, STS);
> + if (!is_T30_compatible) {
> + /* Select UTMI parallel interface */
> + if (config->periph_id == PERIPH_ID_USBD) {
> + clrsetbits_le32(&usbctlr->port_sc1, PTS1_MASK,
> + PTS_UTMI << PTS1_SHIFT);
> + clrbits_le32(&usbctlr->port_sc1, STS1);
> + } else {
> + clrsetbits_le32(&usbctlr->port_sc1, PTS_MASK,
> + PTS_UTMI << PTS_SHIFT);
> + clrbits_le32(&usbctlr->port_sc1, STS);
> + }
> + }
This changes behaviour on Tegra20. While it may be
Re: [U-Boot] [PATCH 1/3] ARM: Tegra: FDT: Add USB support for T20/T30/T114
On 04/29/2013 03:21 AM, Jim Lin wrote:
> Add DT node for USB function.
> diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
> +/* This table has USB timing parameters for each Oscillator frequency we
> + * support. There are four sets of values:
> + *
> + * 1. PLLU configuration information (reference clock is osc/clk_m and
> + * PLLU-FOs are fixed at 12MHz/60MHz/480MHz).
> + * Reference frequency MHZ 12.0 13.0 19.2 26.0
> + *
> + * DIVN 960 960200 960
> + * DIVM 1213 426
> + * CPCON 1212 312
> + * LFCON 2 2 2 2
> + *
> + * 2. PLL CONFIGURATION & PARAMETERS for different clock generators:
> + * Reference frequency MHZ 12.0 13.0 19.2 26.0
> + *
> + * PLLU_ENABLE_DLY_COUNT 02 2 3 4
> + * PLLU_STABLE_COUNT 475175 102
> + * PLL_ACTIVE_DLY_COUNT08 912 9
> + * XTAL_FREQ_COUNT118 127 188 254
> + *
> + * 3. Debounce values IdDig, Avalid, Bvalid, VbusValid, VbusWakeUp, and
> + * SessEnd. Each of these signals have their own debouncer and for each of
> + * those one out of two debouncing times can be chosen (BIAS_DEBOUNCE_A or
> + * BIAS_DEBOUNCE_B).
> + *
> + * The values of DEBOUNCE_A and DEBOUNCE_B are calculated as follows:
> + *0x -> No debouncing at all
> + * ms = * 1000 / (1/19.2MHz) / 4
> + *
> + * So to program a 10 ms debounce for BIAS_DEBOUNCE_A, we have:
> + * BIAS_DEBOUNCE_A[15:0] = 10 * 1000 * 19.2 / 4 = 48000 = 0xBB80
> + *
> + * We need to use only DebounceA for BOOTROM. We don't need the DebounceB
> + * values, so we can keep those to default.
> + *
> + * 4. The 20 microsecond delay after bias cell operation.
> + *UTMIP_BIAS_PAD_TRK_COUNT
> + *
> + * enum {
> + * PARAM_DIVN, // PLL FEEDBACK DIVIDER
> + * PARAM_DIVM, // PLL INPUT DIVIDER
> + * PARAM_DIVP, // POST DIVIDER (2^N)
> + * PARAM_CPCON,// BASE PLLC CHARGE Pump setup ctrl
> + * PARAM_LFCON,// BASE PLLC LOOP FILter setup ctrl
> + * PARAM_ENABLE_DELAY_COUNT, // PLL-U Enable Delay Count
> + * PARAM_STABLE_COUNT, // PLL-U STABLE count
> + * PARAM_ACTIVE_DELAY_COUNT, // PLL-U Active delay count
> + * PARAM_XTAL_FREQ_COUNT, // PLL-U XTAL frequency count
> + * PARAM_DEBOUNCE_A_TIME, // 10MS DELAY for BIAS_DEBOUNCE_A
> + * PARAM_BIAS_TIME,// 20US DELAY AFter bias cell op
> + * // UTMIP_BIAS_PAD_TRK_COUNT
> + *};
> + */
> + usbparams@0 {
> + compatible = "nvidia,usbparams";
> + osc-frequency = <1300>;
> + /* DivN, DivM, DivP, CPCON, LFCON, Delays Debounce, Bias */
> + params = <0x3c0 0x0d 0x00 0xc 2 0x02 0x33 0x09 0x7f 0x7ef4 6>;
> + };
> +
> + usbparams@1 {
> + compatible = "nvidia,usbparams";
> + osc-frequency = <1920>;
> + params = <0x0c8 0x04 0x00 0x3 2 0x03 0x4b 0x0c 0xbc 0xbb80 8>;
> + };
> +
> + usbparams@2 {
> + compatible = "nvidia,usbparams";
> + osc-frequency = <1200>;
> + params = <0x3c0 0x0c 0x00 0xc 2 0x02 0x2f 0x08 0x76 0x7530 5>;
> + };
> +
> + usbparams@3 {
> + compatible = "nvidia,usbparams";
> + osc-frequency = <2600>;
> + params = <0x3c0 0x1a 0x00 0xc 2 0x04 0x66 0x09 0xfe 0xfde8
> 0xb>;
> + };
None of the above should be present; this is SoC-specific information
and should be part of the USB driver itself. There's no benefit to
putting the information into DT just to parse it back out into the same
tables that the driver could have contained in the first place.
The same comment applies to all 3 tegra*.dtsi files. For the Tegra20
case, please make sure that what you add here is identical to what has
been proposed for the final kernel USB bindings. Ask Venu (now CC'd) for
a pointer to that.
> + usb@7d00 {
> + compatible = "nvidia,tegra30-ehci", "nvidia,tegra114-ehci";
> + reg = <0x7d00 0x4000>;
> + interrupts = < 52 >;
There shouldn't be spaces after < or before >.
The bindings here don't match the kernel. Please make sure they do.
This patch only touches 2 board files: Cardhu and Dalmore. Will USB
support on other boards continue to work without any DT changes?
Existing functionality can't be broken. I'd expect to see a bunch more
DT files edited here.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] : Please pull u-boot-mpc5xxx
Dear Tom, The following changes since commit 971020c755e5633c9a8f532356ee1750b38dd86f: sandbox: config: Enable CONFIG_FIT and CONFIG_CMD_FIT (2013-05-01 11:17:21 -0400) are available in the git repository at: git://git.denx.de/u-boot-mpc5xxx.git master for you to fetch changes up to 8aa34499727936ede3f85033380720b4a9522aaa: mpc5200: a3m071/a4m2k: Miscellaneous updates and fixes (2013-05-02 20:46:08 +0200) Anatolij Gustschin (1): mpc512x: remove dead code Stefan Roese (3): mpc5200: a3m071/a4m2k: Enable flash verify option mpc5200: a3m071/a4m2k: Fix problem with increased global_data struct mpc5200: a3m071/a4m2k: Miscellaneous updates and fixes arch/powerpc/cpu/mpc512x/speed.c | 6 --- board/a3m071/a3m071.c| 26 +--- include/common.h | 3 -- include/configs/a3m071.h | 92 4 files changed, 84 insertions(+), 43 deletions(-) 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 Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] mpc5200: a3m071/a4m2k: Miscellaneous updates and fixes
Dear Stefan Roese, In message <1366968023-10646-1-git-send-email...@denx.de> you wrote: > The changes to a3m071/a4m2k in summary are: > - Enable CAN1 on I2C in GPS Port Configuration > - Enable SPI on PSC2 > - Activate network console > - New flash partitioning > - Fix some typos > - Pass host name to Linux > - Change rootfs to squashfs,jffs2 > - Enable UBI/UBIFS support > - Enable FIT support > > Signed-off-by: Stefan Roese > --- > v2: > - Not only redundant env but also some other fixes and updates > included > - Therefore the patch subject has been changed > > board/a3m071/a3m071.c| 26 +++ > include/configs/a3m071.h | 87 > ++-- > 2 files changed, 82 insertions(+), 31 deletions(-) Applied, thanks. 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 The software required `Windows 95 or better', so I installed Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] mpc5200: a3m071/a4m2k: Fix problem with increased global_data struct
Dear Stefan Roese, In message <1366967402-8804-1-git-send-email...@denx.de> you wrote: > The v2013.04 release has this patch set included: > > 5cb48582 "Add architecture-specific global data" > > With this, the global_data struct is now common and new variables > have been added. Resulting in a bigger struct. Unfortunately the > currently allocated 128 bytes are just a bit too small for this > new struct. > > This patch now uses the automatically generated struct size instead to > not run into this problem again. > > Please note that this problem might hit some other platforms which > currently reserve a tight space of 128 bytes for the global_data > struct! > > Signed-off-by: Stefan Roese > --- > v2: > - Use automatically generated struct size instead instead of a fixed > value > > include/configs/a3m071.h | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Applied, thanks. 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 Wenn das dann in die Hose geht, nehme ich es auf meine Kappe. -- Rudi Völler, 15. Nov 2003 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: mxc_spi: Fix pre and post divider calculation
On 5/2/2013 3:59 AM, Dirk Behme wrote:
From: Dirk Behme
Fix two issues with the calculation of pre_div and post_div:
1. pre_div: While the calculation of pre_div looks correct, to set the
CONREG[15-12] bits pre_div needs to be decremented by 1:
The i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM
Rev. 0, 11/2012) states:
CONREG[15-12]: PRE_DIVIDER
Divide by 1
0001 Divide by 2
0010 Divide by 3
...
1101 Divide by 14
1110 Divide by 15
Divide by 16
I.e. if we want to divide by 2, we have to write 1 to CONREG[15-12].
2. In case the post divider becomes necessary, pre_div will be set to 15. To
calculate the post divider, divide by 15, too. And not 16.
Both issues above are tested using the following examples:
clk_src = 6000 (60MHz, default i.MX6 ECSPI clock)
a) max_hz == 2300 (23MHz, max i.MX6 ECSPI read clock)
-> pre_div = 3 (divide by 3 => CONREG[15-12] == 2)
-> post_div = 0 (divide by 1 => CONREG[11- 8] == 0)
=> 60MHz / 3 = 20MHz SPI clock
b) max_hz == 200 (2MHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 1 (divide by 2 => CONREG[11- 8] == 1)
=> 60MHz / 30 = 2MHz SPI clock
c) max_hz == 100 (1MHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 2 (divide by 4 => CONREG[11- 8] == 2)
=> 60MHz / 60 = 1MHz SPI clock
d) max_hz == 50 (500kHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 3 (divide by 8 => CONREG[11- 8] == 3)
=> 60MHz / 120 = 500kHz SPI clock
Signed-off-by: Dirk Behme
---
drivers/spi/mxc_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 5bed858..8630bbd 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -128,7 +128,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
unsigned int max_hz, unsigned int mode)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
- s32 pre_div = 0, post_div = 0, i, reg_ctrl, reg_config;
+ s32 pre_div = 1, post_div = 0, i, reg_ctrl, reg_config;
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs->base;
@@ -153,7 +153,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs,
if (clk_src > max_hz) {
pre_div = DIV_ROUND_UP(clk_src, max_hz);
if (pre_div > 16) {
- post_div = pre_div / 16;
+ post_div = pre_div / 15;
I think this should not change
pre_div = 15;
and this should be = 16, because you now subtract 1 below
}
if (post_div != 0) {
@@ -174,7 +174,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_SELCHAN(3)) |
MXC_CSPICTRL_SELCHAN(cs);
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_PREDIV(0x0F)) |
- MXC_CSPICTRL_PREDIV(pre_div);
+ MXC_CSPICTRL_PREDIV(pre_div - 1);
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_POSTDIV(0x0F)) |
MXC_CSPICTRL_POSTDIV(post_div);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc5200: a3m071/a4m2k: Enable flash verify option
Dear Stefan Roese, In message <1365083742-7802-1-git-send-email...@denx.de> you wrote: > Signed-off-by: Stefan Roese > --- > include/configs/a3m071.h | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. 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 "Ada is PL/I trying to be Smalltalk. - Codoso diBlini ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] mxs: Fix PULLUP/NOPULL definitions
Hi Fabio, > On mx23 and mx28 the pullup bits are defined as: > > - 0: Enable the internal pad keeper > - 1: Disable the internal pad keeper > > Fix the definitions as they are currently the opposite. Sorry, but I think this is not correct. Please have a look at the reference manual for i.MX28 page 786: It seems that some pins have an internal pullup, but other pins "only" have the internal keeper you mentioned. Quote from : bank 0 pin 24: "Set this bit to one to _enable_ the internal pullup..." bank 0 pin 25: "Set this bit to one to _disable_ the internal keeper..." So I think the current implementation is correct. However, if you are trying to enable a pullup for a pin which does not have this function (e.g. because the hardware guys trimmed the BOM and did not spend an external pullup) you are actually disabling the keeper which makes the situation even worse in some situations. I'm still wondering what an ideal solution could be... Best regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc512x: remove dead code
Dear Anatolij Gustschin, In message <1364671596-16584-1-git-send-email-ag...@denx.de> you wrote: > The prt_mpc512x_clks() function isn't referenced > anywhere and its prototype is wrong. Remove it. > > Signed-off-by: Anatolij Gustschin > --- > arch/powerpc/cpu/mpc512x/speed.c |6 -- > include/common.h |3 --- > 2 files changed, 0 insertions(+), 9 deletions(-) Applied, thanks. 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 Politician: An eel in the fundamental mud upon which the superstructure of organized society is reared. When he wriggles he mistakes the agitation of his tail for the trembling of the edifice. As compared with the statesman, he suffers the disadvantage of being alive. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] i2c: s3c24xx: add hsi2c controller support
Hello Heiko, On 2 May 2013 03:06, Heiko Schocher wrote: > Hello Naveen, > > On 01.05.2013 21:04, Naveen Krishna Ch wrote: >> Hello Heiko, >> >> On 29 April 2013 21:14, Heiko Schocher wrote: >>> Hello Naveen, >>> >>> On 26.04.2013 05:08, Naveen Krishna Ch wrote: On 14 April 2013 22:48, Heiko Schocher wrote: > Hello Naveen Krishna, > > > On 13.04.2013 06:42, Naveen Krishna Ch wrote: >> >> On 6 April 2013 07:07, Naveen Krishna Chatradhi >> wrote: >>> >>> Add support for hsi2c controller available on exynos5420. >>> >>> Note: driver currently supports only fast speed mode 100kbps >>> >>> Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43 >>> Signed-off-by: Naveen Krishna Chatradhi >>> Signed-off-by: R. Chandrasekar >>> Reviewed-by: Vadim Bendebury >>> Reviewed-by: Simon Glass >>> --- >>> Changes since v3: >>> >>> 1. Implemented get_timer instead of while and udelay for master busy >>> function >>> 2. Use reg base address from device tree >>> 3. Split the timing function to check for the errors >>> 4. Implemented reset function for to recover from failure cases >>> 5. Implemented a comat string for hsi2c to distingush the channels >>> 6. Minor cosmotic changes >>> >>> Note: FIFOs will be implemented in subsequent patches >>> >>> drivers/i2c/s3c24x0_i2c.c | 494 >>> + >>> drivers/i2c/s3c24x0_i2c.h | 36 >>> 2 files changed, 486 insertions(+), 44 deletions(-) > > [...] > >>> -- >>> 1.7.9.5 >> >> Hello all i got it review by Simon and Vadim. >> Any updates on this driver please > > > As this patch in patchwork is in the responsibilty of Minkyu Kang (why?, > added to cc): > > Reviewed-by: Heiko Schocher > Acked-by: Heiko Schocher Hello Minkyu Kang, This patch was Acked and reviewed a while ago. Can you please update on this. >>> >>> Tom Rini wrote: > Naveen Krishna Ch (1): > i2c: s3c24xx: add hsi2c controller support > > drivers/i2c/s3c24x0_i2c.c | 494 > + > drivers/i2c/s3c24x0_i2c.h | 36 ++ > post/drivers/i2c.c| 2 + > 3 Dateien ge?ndert, 488 Zeilen hinzugef?gt(+), 44 Zeilen entfernt(-) NAK. MAKEALL -a arm: - SUMMARY Boards compiled: 306 Boards with errors: 3 ( snow VCMA9 smdk5250 ) -- And the problem is: s3c24x0_i2c.c: In function 'board_i2c_init': s3c24x0_i2c.c:945:3: error: 'COMPAT_SAMSUNG_EXYNOS5_I2C' undeclared (first use in this function) >>> >>> Please fix, thanks! >> >> I've submitted a patch to u-boot@lists.denx.de as soon as i saw the build >> error. >> >> "fdtdec: Add compatible string for High speed i2c" >> http://www.mail-archive.com/u-boot@lists.denx.de/msg112143.html >> >> which should fix. Can you please confirm the same. > > On current HEAD with your 2 patches, I see: > > [hs@pollux u-boot]$ ./MAKEALL VCMA9 > Configuring for VCMA9 board... > s3c24x0_i2c.c:133:16: error: 'i2c_busses' undeclared (first use in this > function) > s3c24x0_i2c.c:134:11: error: 'i2c_bus' undeclared (first use in this function) > s3c24x0_i2c.c:911:10: error: 'i2c_bus' undeclared (first use in this function) > s3c24x0_i2c.c:923:18: error: 'i2c_busses' undeclared (first use in this > function) > arm-linux-gnueabi-size: './u-boot': No such file > s3c24x0_i2c.c: In function 'get_bus': > s3c24x0_i2c.c:133:16: error: 'i2c_busses' undeclared (first use in this > function) > s3c24x0_i2c.c:133:16: note: each undeclared identifier is reported only once > for each function it appears in > s3c24x0_i2c.c:134:11: error: 'i2c_bus' undeclared (first use in this function) > s3c24x0_i2c.c: In function 'hsi2c_get_clk_details': > s3c24x0_i2c.c:267:2: warning: implicit declaration of function 'get_i2c_clk' > [-Wimplicit-function-declaration] > s3c24x0_i2c.c: In function 'process_nodes': > s3c24x0_i2c.c:911:10: error: 'i2c_bus' undeclared (first use in this function) > s3c24x0_i2c.c:921:3: warning: implicit declaration of function > 'pinmux_decode_periph_id' [-Wimplicit-function-declaration] > s3c24x0_i2c.c:923:18: error: 'i2c_busses' undeclared (first use in this > function) > s3c24x0_i2c.c:924:3: warning: implicit declaration of function > 'exynos_pinmux_config' [-Wimplicit-function-declaration] > s3c24x0_i2c.c: At top level: > s3c24x0_i2c.c:264:12: warning: 'hsi2c_get_clk_details' defined but not used > [-Wunused-function] > s3c24x0_i2c.c:899:13: warning: 'process_nodes' defined but not used > [-Wunused-function] > make[1]: *** [s3c24x0_i2c.o] Fehler 1 > make: *** [drivers/i2c/libi2c.o] Fehler 2 > make: *** War
Re: [U-Boot] Regression from v2013.04-rc3 with sdcard detection
On 04/21/2013 11:29 AM, Nicolas Chauvet wrote: > Hi, > > I'm experiencing a regression from v2013.04-rc3 that I found related to the > following commit: > > 64f4a6192f0670de2d9af98900b750a3e7bf8ce6 > 1741c64d642a95c4bb88a2b03e96c6dc7ed5fe62 > > With v2013.04 release, when trying to boot from sdcard, I have: > "Card did not respond to voltage select" > while detecting the sdcard as mmc 1 > > Without theses commit or with v2013.04-rc3 > **File not found /boot.scr.uimg *** > .and then it find /boot.src on the sdcard. > > This was experienced on the Toshiba AC100, aka paz00 using a tegra20 arm > chipset. I can't reproduce this problem with either v2013.04 or the latest u-boot/master (971020c "sandbox: config: Enable CONFIG_FIT and CONFIG_CMD_FIT"). Perhaps it depends on the specs of the SD card you use; what are yours? Also, you didn't Cc anyone involved in Tegra, MMC, or the patches you're reporting problems with. I have added them to this message. Most likely, nobody saw your email. I only happened to since I returned from vacation, and searched my list folder for any mention of Tegra. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] bfin: Move gpio support for bf54x and bf60x into the generic driver folder.
On Thursday 02 May 2013 01:55:25 Sonic Zhang wrote: > The gpio spec for bf54x and bf60x differ a lot from the old gpio driver for > bf5xx. A lot of machine macros are used to accomodate both code in one > gpio driver. This patch split the old gpio driver and move new gpio2 > support to the generic gpio driver folder. > > - To enable gpio2 driver, macro CONFIG_ADI_GPIO2 should be defined in the > board's config header file. > - The gpio2 driver supports bf54x, bf60x and future ADI processors, while > the older gpio driver supports bf50x, bf51x, bf52x, bf53x and bf561. > - All blackfin specific gpio function names are replaced by the generic > gpio APIs. the code in u-boot was written so as to make direct import from the kernel trivial. that way there is only one code base to maintain -- the kernel. last i looked, you hadn't split the drivers in the kernel, which means things are now diverging. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env_mmc: add support for redundant environment
On Wed, Apr 10, 2013 at 10:36:19AM -, Michael Heimpold wrote: > This patch add support for storing the environment redundant on > mmc devices. Substantially it re-uses the logic from the NAND implementation, > that means using an incremental counter for marking newer data. > > Signed-off-by: Michael Heimpold Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/5] consolidate hang()
On Fri, Apr 19, 2013 at 10:48:45AM +0200, Andreas Bie??mann wrote: > This series started with intention to make a hung board visualize the > (end-)user that it does hang(). The first approach was to make all the > different hang() functions weak and provide board specific versions to > implement the 'visualization' there. > After some discussion it turned out, that there is still an interface to > visualize such states to the user: the 'bootstage' stuff. With a change to 5/5, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mmc: Define a constant for the maximum block size
On Wed, Apr 03, 2013 at 08:54:30AM -, Simon Glass wrote: > The number 512 appears quite a bit in the mmc code. Add a constant for this > so that it can be used here and in other parts of the code (e.g. SPL code > which loads from mmc). > > Signed-off-by: Simon Glass > Reviewed-by: Vadim Bendebury Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/4] part/dev_desc: Add log2 of blocksize to block_dev_desc data struct
On Tue, Apr 09, 2013 at 09:11:56PM -, egbert.e...@gmail.com wrote: > From: Egbert Eich > > log2 of the device block size serves as the shift value used to calculate > the block number to read in file systems when implementing avaiable block > sizes. > It is needed quite often in file systems thus it is pre-calculated and > stored in the block device descriptor. > > Signed-off-by: Egbert Eich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/4] fs/fat: Don't multiply fatsize with sector size
On Tue, Apr 09, 2013 at 09:11:55PM -, egbert.e...@gmail.com wrote: > From: Egbert Eich > > Bugfix: > Here at this place we need the fat size in sectors not bytes. > This was found during code review when adding support for storage > devices with blocksizes != 512. > > Signed-off-by: Egbert Eich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/4] disk/iso: Add Support for block sizes > 512 byte to ISO partition support
On Tue, Apr 09, 2013 at 09:11:54PM -, egbert.e...@gmail.com wrote: > From: Egbert Eich > > For ISO we check the block size of the device if this is != the CD sector > size we assume that the device has no ISO partition. > > Signed-off-by: Egbert Eich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] disk/gpt: Fix GPT partition handling for blocksize != 512
On Tue, Apr 09, 2013 at 06:03:36AM -, egbert.e...@gmail.com wrote: > From: Egbert Eich > > Disks beyond 2T in size use blocksizes of 4096 bytes. However a lot of > code in u-boot still assumes a 512 byte blocksize. > This patch fixes the handling of GPTs. > > Signed-off-by: Egbert Eich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] disk/part_dos: check harder for partition table
On Tue, Apr 09, 2013 at 05:46:14AM -, egbert.e...@gmail.com wrote: > From: Egbert Eich > > Devices that used to have a whole disk FAT filesystem but got then > partitioned will most likely still have a FAT or FAT32 signature > in the first sector as this sector does not get overwritten by > a partitioning tool (otherwise the tool would risk to kill the mbr). > > The current partition search algorithm will erronously detects such > a device as a raw FAT device. > > Instead of looking for the FAT or FAT32 signatures immediately we > use the same algorithm as used by the Linux kernel and first check > for a valid boot indicator flag on each of the 4 partitions. > If the value of this flag is invalid for the first entry we then > do the raw partition check. > If the flag for any higher partition is wrong we assume the device > is neiter a MBR nor PBR device. > > Signed-off-by: Egbert Eich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/11] Add Regular Expressions Support
On Sun, Mar 24, 2013 at 10:50:27AM +0100, Wolfgang Denk wrote:
> The following patch series adds the SLRE "Super Light Regular
> Expression" library and uses this to add regex support for
> the "env grep" (aka "grepenv") command, and new functions (or
> operators?) "gsub" and "sub" to the "setexpr" command.
>
> The rework to "env grep" also fixed a few bugs (which caused it to
> dump always _all_ environment variables on some systems), and adds
> the capability to grep in either the variable name, or the value, or
> in both (the old version always did the latter). Instead of special
> functions we now use common code (i. e. hexport_r()) for the variable
> look-up, which gives us sorted output as a free additional benefit.
>
> This allows to do things like
>
> - print all MAC addresses:
>
> => env grep -e eth.*addr
> eth1addr=00:10:ec:80:c5:15
> ethaddr=00:10:ec:00:c5:15
>
> - print all variables that have at least 2 colons in their value:
>
> => env grep -v -e :.*:
> addip=setenv bootargs ${bootargs}
> ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off
> panic=1
> eth1addr=00:10:ec:80:c5:15
> ethaddr=00:10:ec:00:c5:15
> ver=U-Boot 2013.04-rc1-00289-g497746b-dirty (Mar 22 2013 - 12:50:25)
>
> - Generate broadcast address by substituting the last two numbers of
> the IP address by "255.255":
>
> => print ipaddr
> ipaddr=192.168.1.104
> => setexpr broadcast sub "(.*\\.).*\\..*" "\\1255.255" $ipaddr
> broadcast=192.168.255.255
>
> - Depending on keyboard configuration (German vs. US keyboard) a
> bar code scanner may initialize the MAC address as C0:E5:4E:02:06:DC
> or as C0>E5>4E>02>06>DC. Make sure we always have a correct value:
>
> => print ethaddr
> ethaddr=C0>E5>4E>02>06>DC
> => setexpr ethaddr gsub > :
> ethaddr=C0:E5:4E:02:06:DC
>
> etc.
>
> Regex support can be enabled by defining CONFIG_REGEX in the board
> config file.
>
> Notes:
>
> - This patch series has been compile-tested (and found to be clean
> with ELDK v5.3) on all of the following boards:
>
> ARM: m28evk
>
> PPC4xx: acadia bamboo bluestone bubinga canyonlands dlvision-10g
> dlvision ebony gdppc440etx icon intip io io64 iocon katmai kilauea
> luan makalu neo ocotea redwood sequoia t3corp taihu taishan walnut
> yosemite yucca
>
> - Runtime / functional testing has been done mostly on PPC (Sequoia
> board).
>
>
> Changes in v2:
> - fixed trailing whitespace errors
> - Note 1: The "line over 80 characters" warning will NOT be fixed due
> to the "never break user-visible strings" rule.
> - Note 2: The "Alignment should match open parenthesis" check will NOT
> be fixed due to the "indent by TABs only" rule.
> - Fix ERROR: "foo * bar" should be "foo *bar" errors
> - Fix trailing whitespace error
> - Note: the "Alignment should match open parenthesis" check will not
> be fixed due to the "indent always byy TABs" rule.
> - no changes; most of this is imported code and is intentionally left
> as is
> - the "Alignment should match open parenthesis" check is left due to
> the "indent only by TABs" rule
> - the "line over 80 characters" warning is left due to the "never
> break user-visible strings" rule
> - Fix trailing whitespace error
> - fix "No space is necessary after a cast" checks
> - fix "space prohibited before semicolon" and "space required after
> that ';'" errors (but I onsider the result less readable :-( )
> - Note: the remaining warnings ("line over 80 characters") and checks
> ("Alignment should match open parenthesis") are intentionally left
> as is.
> - Do the white space cleanup globally, and as separate patch
>
> Wolfgang Denk (11):
> hashtable: preparations to use hexport_r() for "env grep"
> "env grep" - reimplement command using hexport_r()
> "env grep" - add options to grep in name, value, or both.
> Add SLRE - Super Light Regular Expression library
> "env grep" - add support for regular expression matches
> setexpr: simplify code, improve help message
> setexpr: add regex substring matching and substitution
> m28evk: white space cleanup
> m28evk: enable "env grep" and regexp support
> amcc-common.h: minor white space cleanup
> amcc-common.h: enable support for "env grep", "setexpr", and regex.
>
> README| 7 +
> common/cmd_nvedit.c | 87 +++--
> common/cmd_setexpr.c | 296 -
> include/configs/amcc-common.h | 9 +-
> include/configs/m28evk.h | 259 +++
> include/search.h | 15 +-
> include/slre.h| 100 ++
> lib/Makefile | 1 +
> lib/hashtable.c | 93 --
> lib/slre.c| 724
> ++
> 10 files changed, 1391 insertions(+), 200 deletions(-)
> create mode 100644 include/slre.h
> create mode 100644 lib/slre.c
Applied to
Re: [U-Boot] [PATCH v3 5/5] lib: consolidate hang()
On Fri, Apr 19, 2013 at 10:48:50AM +0200, Andreas Bie??mann wrote:
> Delete all occurrences of hang() and provide a generic function.
>
> Signed-off-by: Andreas Bie??mann
With the following:
diff --git a/lib/hang.c b/lib/hang.c
index ef82f7f..fc1286c 100644
--- a/lib/hang.c
+++ b/lib/hang.c
@@ -37,7 +37,8 @@
*/
void hang(void)
{
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_SPL_BUILD) || (defined(CONFIG_SPL_LIBCOMMON_SUPPORT) && \
+ defined(CONFIG_SPL_SERIAL_SUPPORT))
puts("### ERROR ### Please RESET the board ###\n");
#endif
bootstage_error(BOOTSTAGE_ID_NEED_RESET);
To fix build breakage when LIBCOMMON is set, but SERIAL is not and thus
we had a build failure, applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spl_mmc: cleanup variable types
On Thu, Mar 21, 2013 at 04:55:17AM -, Peter Korsgaard wrote: > block_read returns unsigned long, so it doesn't make sense to check for > < 0. and neither does marking the header structure as const and then > casting away the constness to load data into it. > > Also cleanup some unneeded pointer casting while we're at it. > > Signed-off-by: Peter Korsgaard > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx28evk: Guard NAND-related ENV defines with CONFIG_ENV_IS_IN_NAND
On Tue, Apr 30, 2013 at 04:05:17PM -0400, Tom Rini wrote: > The redundancy related defines are only correct for NAND, so guard all > of that area with CONFIG_ENV_IS_IN_NAND > > Cc: Fabio Estevam > Signed-off-by: Tom Rini Along with 2/2 (and typo fix), applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/11] net: add Faraday FTMAC110 10/100Mbps ethernet support
On Fri, Apr 26, 2013 at 04:02:32PM +0800, Kuo-Jung Su wrote:
> From: Kuo-Jung Su
[snip]
> + | (phyaddr << PHYCR_ADDR_SHIFT)
> + | (phyreg << PHYCR_REG_SHIFT)
> + | 0x3000;
Magic number.
> +
> + writel(tmp, ®s->phycr);
> +
> + for (ts = get_timer(0); get_timer(ts) < 1000; ) {
Please define a TIMEOUT and use that insteadof 1000 all the time.
[snip]
> + /* interrupt at every packet transmit/receive */
> + writel(0x1010, ®s->itc);
> + /* tx/rx poll interval=5.12us; rx_poll_cnt=1 */
> + writel(0x0001, ®s->aptc);
> + /* rx fifo: high=1536, low=512 */
> + writel(0x0390, ®s->dblac);
> + /* clear all interrupt status */
> + writel(0x03FF, ®s->isr);
More magic numbers. Please fix globally. 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 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
Jim, > -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, May 02, 2013 4:39 AM > To: Jim Lin > Cc: Tom Rini; u-boot@lists.denx.de; Tom Warren; Stephen Warren; Tom > Warren > Subject: Re: [U-Boot] [PATCH 2/3] ARM: Tegra: USB: Add driver support for > Tegra30/Tegra114 > > Dear Jim Lin, > > [...] > > > > > > > This is a problem with the struct-based access indeed. I agree with > > > Tom it'd be worth to at least try distilling the common part into > > > header shared between those three CPUs. > > > > OK. I will add this into next version of patch. I did a quick hack for arch-tegra/usb.h (common defines) and arch-tegra114/usb.h (register struct plus some unique defines) that I'll send you as an example. > > > > > btw you're also adding some kernel-doc-alike annotations to > > > functions, why don't you follow kerneldoc style altogether? > > > > I don't understand what you meant here. > > Could you give me an example? Like what I did is wrong or not good. > > And what is correct or better one. > > These kinds of annotations: > > +/* > + * Process a list of nodes, adding them to our list of SDMMC ports. > + * > + * @param blob fdt blob > + * @param node_list list of nodes to process (any <=0 are ignored) > + * @param count number of nodes to process > + * @return 0 if ok, -1 on error > + */ > > See http://www.denx.de/wiki/U-Boot/CodingStyle at the bottom for the > right style. Note that the 'SDMMC ports' part s/b 'USB ports', or 'USB controllers'. Please change it. Marek is asking why we have inconsistent function commenting in ehci-tegra.c - read the kernel.doc howto pointed to in the URL above, and make sure any function/struct/enum comments adhere to that style (/** to start, Return: instead of @return, etc.), so that one can run the kernel-doc scripts and extract info about our EHCI driver's functions, etc. This is something I'll look at doing in all the Tegra-specific drivers and source in a future patchset. Tom > > Best regards, > Marek Vasut -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 8/8] mxs: spl_mem_init: Change EMI port priority
FSL bootlets code set the PORT_PRIORITY_ORDER field of register HW_EMI_CTRL as 0x2, which means: PORT0231 = 0x02 Priority Order: AXI0, AHB2, AHB3, AHB1 Signed-off-by: Fabio Estevam --- Changes since v1: - None arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index bf58058..5d881da 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -286,7 +286,7 @@ static void mx23_mem_init(void) early_delay(2); /* Adjust EMI port priority. */ - clrsetbits_le32(0x8002, 0x1f << 16, 0x8); + clrsetbits_le32(0x8002, 0x1f << 16, 0x2); early_delay(2); setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 19); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/8] mxs: spl_mem_init: Fix comment about start bit
Start bit is part of HW_DRAM_CTL8 register, so fix the comment. Signed-off-by: Fabio Estevam --- Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 4950490..300da0a 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -267,7 +267,7 @@ static void mx23_mem_init(void) initialize_dram_values(); - /* Set START bit in DRAM_CTL16 */ + /* Set START bit in DRAM_CTL8 */ setbits_le32(MXS_DRAM_BASE + 0x20, 1 << 16); clrbits_le32(MXS_DRAM_BASE + 0x40, 1 << 17); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as "reserved".
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- To avoid polluting the mx28 case, separate the function definition in mx23 and
for mx28.
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index df25535..bf58058 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -110,6 +110,7 @@ __weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
}
+#ifdef CONFIG_MX28
static void initialize_dram_values(void)
{
int i;
@@ -118,15 +119,26 @@ static void initialize_dram_values(void)
for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+}
+#else
+static void initialize_dram_values(void)
+{
+ int i;
+
+ mxs_adjust_memory_params(dram_vals);
+
+ for (i = 0; i < ARRAY_SIZE(dram_vals); i++) {
+ if (!(i == 8 || i == 27 || i == 28 || i == 35))
+ writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+ }
-#ifdef CONFIG_MX23
/*
* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
* element to be set
*/
writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
-#endif
}
+#endif
static void mxs_mem_init_clock(void)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/8] mx23_olinuxino: Fix DDR pin iomux settings
Change MUX_CONFIG_EMI to use the same voltage selection/drive strength and
pullup settings as the bootlets code from Freescale, which results in much
better stability.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/olimex/mx23_olinuxino/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index a96c293..e55947f 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -29,7 +29,7 @@
#include
#include
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
#defineMUX_CONFIG_SSP (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/8] mx23: Fix pad voltage selection bit
On mx23 the pad voltage selection bit needs to be always '0', since '1' is a reserved value. For example: Pin 108, EMI_A06 pin voltage selection: 0= 1.8V (mDDR) or 2.5V (DDR1); 1= reserved. Fix the pad voltage definitions for the mx23 case. Signed-off-by: Fabio Estevam --- Changes since v1: - Newly introduced arch/arm/include/asm/arch-mxs/iomux.h |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 4288715..66dcd36 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -70,8 +70,13 @@ typedef u32 iomux_cfg_t; #define PAD_12MA 2 #define PAD_16MA 3 +#if defined CONFIG_MX28 #define PAD_1V80 #define PAD_3V31 +#else +#define PAD_1V80 +#define PAD_3V30 +#endif #define PAD_NOPULL 0 #define PAD_PULLUP 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/9] mx23: Make DDR initialization stable
Prior to this series running 'memtester' utility in Linux on a mx23evk always resulted in many errors during stress testing, if the kernel is loaded via U-boot. Running the same test and loading the kernel via FSL bootlets resulted on zero errors. Adjust U-boot so that it can also pass the 'memtester' stress test. After this series was applied, no more DDR errors were observed on a mx23evk. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/8] mx23evk: Fix DDR pin iomux settings
Change MUX_CONFIG_EMI to use the same voltage selection/drive strength and
pullup settings as the bootlets code from Freescale, which results in much
better stability.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/freescale/mx23evk/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index b6f4e7e..fd6b3d9 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -26,7 +26,7 @@
#include
#defineMUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/8] mxs: spl_mem_init: Remove erroneous DDR setting
On mx23 there is no 'DRAM init complete' in register HW_DRAM_CTL18. Remove this erroneous setting. Signed-off-by: Fabio Estevam --- Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |4 1 file changed, 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 300da0a..df25535 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -279,10 +279,6 @@ static void mx23_mem_init(void) setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 19); setbits_le32(MXS_DRAM_BASE + 0x40, 1 << 11); - - /* Wait for bit 10 (DRAM init complete) in DRAM_CTL18 */ - while (!(readl(MXS_DRAM_BASE + 0x48) & (1 << 10))) - ; } #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 v2 2/8] mxs: Fix PULLUP/NOPULL definitions
On mx23 and mx28 the pullup bits are defined as: - 0: Enable the internal pad keeper - 1: Disable the internal pad keeper Fix the definitions as they are currently the opposite. Cc: Lauri Hintsala Signed-off-by: Fabio Estevam --- This affects mx28 as well, so also adding Lauri. I also tested on mx28evk and behavior is fine after this change. Changes since v1: - Newly introduced arch/arm/include/asm/arch-mxs/iomux.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 66dcd36..70300d5 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -78,8 +78,8 @@ typedef u32 iomux_cfg_t; #define PAD_3V30 #endif -#define PAD_NOPULL 0 -#define PAD_PULLUP 1 +#define PAD_PULLUP 0 +#define PAD_NOPULL 1 #define MXS_PAD_4MA((PAD_4MA << MXS_PAD_MA_SHIFT) | \ MXS_PAD_MA_VALID_MASK) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
Dear Jim Lin, [...] > > > > This is a problem with the struct-based access indeed. I agree with Tom > > it'd be worth to at least try distilling the common part into header > > shared between those three CPUs. > > OK. I will add this into next version of patch. > > > btw you're also adding some kernel-doc-alike annotations to functions, > > why don't you follow kerneldoc style altogether? > > I don't understand what you meant here. > Could you give me an example? Like what I did is wrong or not good. And > what is correct or better one. These kinds of annotations: +/* + * Process a list of nodes, adding them to our list of SDMMC ports. + * + * @param blob fdt blob + * @param node_list list of nodes to process (any <=0 are ignored) + * @param count number of nodes to process + * @return 0 if ok, -1 on error + */ See http://www.denx.de/wiki/U-Boot/CodingStyle at the bottom for the right style. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spi: mxc_spi: Fix pre and post divider calculation
From: Dirk Behme
Fix two issues with the calculation of pre_div and post_div:
1. pre_div: While the calculation of pre_div looks correct, to set the
CONREG[15-12] bits pre_div needs to be decremented by 1:
The i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM
Rev. 0, 11/2012) states:
CONREG[15-12]: PRE_DIVIDER
Divide by 1
0001 Divide by 2
0010 Divide by 3
...
1101 Divide by 14
1110 Divide by 15
Divide by 16
I.e. if we want to divide by 2, we have to write 1 to CONREG[15-12].
2. In case the post divider becomes necessary, pre_div will be set to 15. To
calculate the post divider, divide by 15, too. And not 16.
Both issues above are tested using the following examples:
clk_src = 6000 (60MHz, default i.MX6 ECSPI clock)
a) max_hz == 2300 (23MHz, max i.MX6 ECSPI read clock)
-> pre_div = 3 (divide by 3 => CONREG[15-12] == 2)
-> post_div = 0 (divide by 1 => CONREG[11- 8] == 0)
=> 60MHz / 3 = 20MHz SPI clock
b) max_hz == 200 (2MHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 1 (divide by 2 => CONREG[11- 8] == 1)
=> 60MHz / 30 = 2MHz SPI clock
c) max_hz == 100 (1MHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 2 (divide by 4 => CONREG[11- 8] == 2)
=> 60MHz / 60 = 1MHz SPI clock
d) max_hz == 50 (500kHz)
-> pre_div = 15 (divide by 15 => CONREG[15-12] == 14)
-> post_div = 3 (divide by 8 => CONREG[11- 8] == 3)
=> 60MHz / 120 = 500kHz SPI clock
Signed-off-by: Dirk Behme
---
drivers/spi/mxc_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 5bed858..8630bbd 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -128,7 +128,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
unsigned int max_hz, unsigned int mode)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
- s32 pre_div = 0, post_div = 0, i, reg_ctrl, reg_config;
+ s32 pre_div = 1, post_div = 0, i, reg_ctrl, reg_config;
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs->base;
@@ -153,7 +153,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
if (clk_src > max_hz) {
pre_div = DIV_ROUND_UP(clk_src, max_hz);
if (pre_div > 16) {
- post_div = pre_div / 16;
+ post_div = pre_div / 15;
pre_div = 15;
}
if (post_div != 0) {
@@ -174,7 +174,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_SELCHAN(3)) |
MXC_CSPICTRL_SELCHAN(cs);
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_PREDIV(0x0F)) |
- MXC_CSPICTRL_PREDIV(pre_div);
+ MXC_CSPICTRL_PREDIV(pre_div - 1);
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_POSTDIV(0x0F)) |
MXC_CSPICTRL_POSTDIV(post_div);
--
1.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] i2c: s3c24xx: add hsi2c controller support
Hello Naveen, On 01.05.2013 21:04, Naveen Krishna Ch wrote: > Hello Heiko, > > On 29 April 2013 21:14, Heiko Schocher wrote: >> Hello Naveen, >> >> On 26.04.2013 05:08, Naveen Krishna Ch wrote: >>> On 14 April 2013 22:48, Heiko Schocher wrote: Hello Naveen Krishna, On 13.04.2013 06:42, Naveen Krishna Ch wrote: > > On 6 April 2013 07:07, Naveen Krishna Chatradhi > wrote: >> >> Add support for hsi2c controller available on exynos5420. >> >> Note: driver currently supports only fast speed mode 100kbps >> >> Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43 >> Signed-off-by: Naveen Krishna Chatradhi >> Signed-off-by: R. Chandrasekar >> Reviewed-by: Vadim Bendebury >> Reviewed-by: Simon Glass >> --- >> Changes since v3: >> >> 1. Implemented get_timer instead of while and udelay for master busy >> function >> 2. Use reg base address from device tree >> 3. Split the timing function to check for the errors >> 4. Implemented reset function for to recover from failure cases >> 5. Implemented a comat string for hsi2c to distingush the channels >> 6. Minor cosmotic changes >> >> Note: FIFOs will be implemented in subsequent patches >> >> drivers/i2c/s3c24x0_i2c.c | 494 >> + >> drivers/i2c/s3c24x0_i2c.h | 36 >> 2 files changed, 486 insertions(+), 44 deletions(-) [...] >> -- >> 1.7.9.5 > > Hello all i got it review by Simon and Vadim. > Any updates on this driver please As this patch in patchwork is in the responsibilty of Minkyu Kang (why?, added to cc): Reviewed-by: Heiko Schocher Acked-by: Heiko Schocher >>> Hello Minkyu Kang, >>> >>> This patch was Acked and reviewed a while ago. >>> Can you please update on this. >> >> Tom Rini wrote: Naveen Krishna Ch (1): i2c: s3c24xx: add hsi2c controller support drivers/i2c/s3c24x0_i2c.c | 494 + drivers/i2c/s3c24x0_i2c.h | 36 ++ post/drivers/i2c.c| 2 + 3 Dateien ge?ndert, 488 Zeilen hinzugef?gt(+), 44 Zeilen entfernt(-) >>> >>> NAK. MAKEALL -a arm: >>> - SUMMARY >>> Boards compiled: 306 >>> Boards with errors: 3 ( snow VCMA9 smdk5250 ) >>> -- >>> >>> And the problem is: >>> s3c24x0_i2c.c: In function 'board_i2c_init': >>> s3c24x0_i2c.c:945:3: error: 'COMPAT_SAMSUNG_EXYNOS5_I2C' undeclared >>> (first use in this function) >> >> Please fix, thanks! > > I've submitted a patch to u-boot@lists.denx.de as soon as i saw the build > error. > > "fdtdec: Add compatible string for High speed i2c" > http://www.mail-archive.com/u-boot@lists.denx.de/msg112143.html > > which should fix. Can you please confirm the same. On current HEAD with your 2 patches, I see: [hs@pollux u-boot]$ ./MAKEALL VCMA9 Configuring for VCMA9 board... s3c24x0_i2c.c:133:16: error: 'i2c_busses' undeclared (first use in this function) s3c24x0_i2c.c:134:11: error: 'i2c_bus' undeclared (first use in this function) s3c24x0_i2c.c:911:10: error: 'i2c_bus' undeclared (first use in this function) s3c24x0_i2c.c:923:18: error: 'i2c_busses' undeclared (first use in this function) arm-linux-gnueabi-size: './u-boot': No such file s3c24x0_i2c.c: In function 'get_bus': s3c24x0_i2c.c:133:16: error: 'i2c_busses' undeclared (first use in this function) s3c24x0_i2c.c:133:16: note: each undeclared identifier is reported only once for each function it appears in s3c24x0_i2c.c:134:11: error: 'i2c_bus' undeclared (first use in this function) s3c24x0_i2c.c: In function 'hsi2c_get_clk_details': s3c24x0_i2c.c:267:2: warning: implicit declaration of function 'get_i2c_clk' [-Wimplicit-function-declaration] s3c24x0_i2c.c: In function 'process_nodes': s3c24x0_i2c.c:911:10: error: 'i2c_bus' undeclared (first use in this function) s3c24x0_i2c.c:921:3: warning: implicit declaration of function 'pinmux_decode_periph_id' [-Wimplicit-function-declaration] s3c24x0_i2c.c:923:18: error: 'i2c_busses' undeclared (first use in this function) s3c24x0_i2c.c:924:3: warning: implicit declaration of function 'exynos_pinmux_config' [-Wimplicit-function-declaration] s3c24x0_i2c.c: At top level: s3c24x0_i2c.c:264:12: warning: 'hsi2c_get_clk_details' defined but not used [-Wunused-function] s3c24x0_i2c.c:899:13: warning: 'process_nodes' defined but not used [-Wunused-function] make[1]: *** [s3c24x0_i2c.o] Fehler 1 make: *** [drivers/i2c/libi2c.o] Fehler 2 make: *** Warte auf noch nicht beendete Prozesse... - SUMMARY Boards compiled: 1 Boards with errors: 1 ( VCMA9 ) -- [hs@pollux u-
Re: [U-Boot] [PATCH 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
On Thu, 2013-05-02 at 03:33 +0800, Marek Vasut wrote: > Dear Tom Rini, > > > On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote: > > > Tom, > > > > > > On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote: > > > > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote: > > > > > Marek, > > > > > > > > > > > -Original Message- > > > > > > From: Marek Vasut [mailto:ma...@denx.de] > > > > > > Sent: Monday, April 29, 2013 4:47 PM > > > > > > To: Jim Lin > > > > > > Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren > > > > > > Subject: Re: [PATCH 2/3] ARM: Tegra: USB: Add driver support for > > > > > > Tegra30/Tegra114 > > > > > > > > > > > > Dear Jim Lin, > > > > > > > > > > > > > Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms to > > > > > > > finish Port Reset. T114 takes > > > > > > > > > > > > > >50 ms. > > > > > > > > > > > > > > 2. PLL parameters > > > > > > > > > > > > > > Tested on Tegra20 Harmony/Seaboard, Tegra30 Cardhu, and Tegra114 > > > > > > > Dalmore platforms. All works well. > > > > > > > > > > > > > > Signed-off-by: Jim Lin > > > > > > > --- > > > > > > > > > > > > > > arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + > > > > > > > arch/arm/include/asm/arch-tegra/usb.h | 249 > > > > > > > -- arch/arm/include/asm/arch-tegra114/tegra.h | > > > > > > > 1 + > > > > > > > arch/arm/include/asm/arch-tegra114/usb.h | 287 > > > > > > > > > > > > + > > > > > > > > > > > > > arch/arm/include/asm/arch-tegra20/usb.h| 279 > > > > > > > > > > > > + > > > > > > > > > > > > > arch/arm/include/asm/arch-tegra30/usb.h| 294 > > > > > > > > > > > > ++ > > > > > > > > > > > > Do we now have three copies of the same stuff ? > > > > > > > > > > When only T20 was supported (for USB), there was a common > > > > > (arch-tegra/usb.h) header. That's been moved to arch-tegra20/usb.h, > > > > > and (unfortunately) there are 2 new usb.h files due to the HW > > > > > differences in the registers between T20 and T30/T114. I don't see > > > > > any easy way to have a common usb.h file for Tegra w/o adding ugly > > > > > #ifdefs to the USB register space struct(s). > > > > > > > > Just how different are they? Are all of the related defines and masks > > > > different too? Do we have conflicts? Moved registers? Just > > > > conflicting values? A quick peek shows '30' and '114' are pretty > > > > similar, except for masks. Maybe splitting the struct up so you can > > > > discard some of the reserved gaps, run-time checking to see if we can > > > > or cannot use a particular part of the struct? > > > > > > This is really Jim's patchset (and his specialty), but here's what I know > > > about Tegra USB regs: > > > > > > T20 had a gap in the registers @ offset 0x130. T30 (and T114) moved the > > > offset of the command/status/interrupt regs down to fill in this gap, > > > which dragged all the subsequent registers back 16 bytes. The two SoCs > > > 'families' sync up again at offset 0x400 and are pretty much equal from > > > there on out to 0x840. > > > > > > The defines are probably 90% the same, with some weirdness for the first > > > USB controller (USB1) and its PTS/STS bits that differs in offset from > > > the other 2 controllers (again, no clue why the HW guys would do this). > > > > > > So we could have the 3 different USB headers in the arch-tegraXX area > > > contain the register structs, and have a common arch-tegra/usb.h that has > > > the #defines that are the same, and is included in the arch-tegraxx/usb.h > > > files. That would reduce this down somewhat, without the ugliness of > > > #ifdefs in the structs. > > > > > > What do you think? > > > > Sounds like the best we can do then. It's probable that trying to > > define USB_REGMAP_GAPSIZE1/2 or whatever to do it on the fly would just > > be uglier still. Thanks! > > This is a problem with the struct-based access indeed. I agree with Tom it'd > be > worth to at least try distilling the common part into header shared between > those three CPUs. OK. I will add this into next version of patch. > > btw you're also adding some kernel-doc-alike annotations to functions, why > don't > you follow kerneldoc style altogether? I don't understand what you meant here. Could you give me an example? Like what I did is wrong or not good. And what is correct or better one. Thanks. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
