[U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board

[Wang Huan-B18965]

Hi, Benoit,

> 
> On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote:
> > MVF600TWR is a board based on Vybrid MVF600 SoC.
> >
> > This patch adds basic support for Vybrid MVF600TWR board.
> >
> > Signed-off-by: Alison Wang <b18965 at freescale.com>
> > Signed-off-by: Jason Jin <Jason.jin at freescale.com>
> > Signed-off-by: TsiChung Liew <tsicliew at gmail.com>
> 
> [...]
> 
> > diff --git a/board/freescale/mvf600twr/mvf600twr.c
> > b/board/freescale/mvf600twr/mvf600twr.c
> > new file mode 100644
> > index 0000000..71ee12b
> > --- /dev/null
> > +++ b/board/freescale/mvf600twr/mvf600twr.c
> > @@ -0,0 +1,413 @@
> > +/*
> > + * Copyright 2013 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License 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
> > + */
> > +
> > +#include <common.h>
> > +#include <asm/io.h>
> > +#include <asm/arch/imx-regs.h>
> > +#include <asm/arch/mvf_pins.h>
> > +#include <asm/arch/crm_regs.h>
> > +#include <asm/arch/clock.h>
> > +#include <mmc.h>
> > +#include <fsl_esdhc.h>
> > +#include <miiphy.h>
> > +#include <netdev.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#define UART_PAD_CTRL	(PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED
> | \
> > +			PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
> > +
> > +#define ESDHC_PAD_CTRL	(PAD_CTL_PUE | PAD_CTL_PUS_100K_UP | \
> > +			PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_20ohm | \
> > +			PAD_CTL_OBE_IBE_ENABLE)
> 
> With the changes that I have suggested in my review of your IOMUX patch,
> ESDHC_PAD_CTRL could be simplified by removing PAD_CTL_PUE.
> 
> And without those changes, UART_PAD_CTRL and ENET_PAD_CTRL in your
> current code set pull values that are actually unused (unless the
> corresponding PKE/PUE bits do not exist and default to pull in the pad
> control registers used with these definitions).
[Alison Wang] Agree.
> 
> > +
> > +#define ENET_PAD_CTRL	(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH
> | \
> > +			PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> > +
> > +#define DDR_PAD_CTRL	PAD_CTL_DSE_25ohm
> 
> MUX_PAD_CTRL() could be added to the 4 pad control definitions above in
> order to avoid repeating it everywhere below. But using MUX_PAD_CTRL()
> relies on the fact that the pad control values in mvf_pins.h are all 0
> (which is the case, but this is dangerous if this is changed later), so
> a better approach could be to use NEW_PAD_CTRL(), e.g.:
>         NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL),
> instead of:
>         MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> 
> > +
[Alison Wang] I have a question about using NEW_PAD_CTRL(). If NEW_PAD_CTRL()
is used, should the pad control values for MVF600_PAD_DDR_A15__DDR_A_15 in mvf_pins.h
be the same as DDR_PAD_CTRL? I saw you didn't use the same value on other platforms,
how do you define it?

Best Regards,
Alison Wang