[patch 0/9] efikamx support improvements

[patch 0/9] efikamx support improvements

[Arnaud Patard (Rtp)]

Hi,

This patchset aims at improving current efikamx support. It adds support for :
- board id detection
- sdhc
- leds
- power button
- spi nor
- reset

I also had to fix/improve some imx51 iomux header so there are patches for
iomux-mx51.h.


Regards,
Arnaud

[patch 1/9] efikamx: read board id

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: efika_boardid.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/c438d891/attachment.ksh>

[patch 2/9] efikamx: add mmc support

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: efika_mmc.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/b08ec8b5/attachment.ksh>

[patch 3/9] imx51: enhance/fix iomux configuration

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: imx51_fix_iomux_gpio_1_x.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/6a080e5b/attachment.ksh>

[patch 4/9] imx51: add gpio mode for csi1 {h,v}sync

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: imx51_add_csi1_hvsync_gpio.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/909bca83/attachment.ksh>

[patch 5/9] efikamx: add leds support

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: efikamx_add_leds.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/845a2b60/attachment.ksh>

[patch 6/9] efikamx: add support for power key

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: efikamx_add_powerkey.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/b320041e/attachment.ksh>

[patch 7/9] imx51: fix gpio_4_24 and gpio_4_25 pad configuration

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: imx51_fix_iomux_gpio_4_24_25.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/b71cd04e/attachment.ksh>

[patch 8/9] efikamx: add spi nor support

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: efikamx_add_nor.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/96d0a42d/attachment.ksh>

[patch 9/9] efikamx: add reset

[Arnaud Patard (Rtp)]

An embedded and charset-unspecified text was scrubbed...
Name: efikamx_reset.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/e771e48a/attachment.ksh>

[patch 3/9] imx51: enhance/fix iomux configuration

[Sascha Hauer]

On Tue, Oct 19, 2010 at 10:42:56PM +0200, Arnaud Patard wrote:
> - ALT0 is used to set GPIO mode of GPIO_1_{2,3,4,5,6,7,8,9} but it's ALT1
> for GPIO_1_{0,1}.
> - add definition to configure pads as ESDHC{1,2} WP and CD
> 
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> Index: linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h
> ===================================================================
> --- linux-2.6.orig/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:22:06.000000000 +0200
> +++ linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:23:22.000000000 +0200
> @@ -366,20 +366,24 @@
>  							MX51_SDHCI_PAD_CTRL)
>  #define MX51_PAD_SD2_DATA3__SD2_DATA3		IOMUX_PAD(0x7D0, 0x3C8, IOMUX_CONFIG_SION, 0x0, 0, \
>  							MX51_SDHCI_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_0__ESDHC1_CD		IOMUX_PAD(0x7B4, 0x3AC, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
>  #define MX51_PAD_GPIO_1_0__GPIO_1_0		IOMUX_PAD(0x7B4, 0x3AC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_1__ESDHC1_WP		IOMUX_PAD(0x7B8, 0x3B0, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
>  #define MX51_PAD_GPIO_1_1__GPIO_1_1		IOMUX_PAD(0x7B8, 0x3B0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>  #define MX51_PAD_GPIO_1_2__I2C2_SCL		IOMUX_PAD(0x7D4, 0x3CC, (2 | IOMUX_CONFIG_SION), \
>  							0x9b8,   3, MX51_I2C_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>  #define MX51_PAD_GPIO_1_3__I2C2_SDA		IOMUX_PAD(0x7D8, 0x3D0, (2 | IOMUX_CONFIG_SION), \
>  							0x9bc,   3, MX51_I2C_PAD_CTRL)
>  #define MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ	IOMUX_PAD(0x7FC, 0x3D4, 0, 0x0,   0, NO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_7__ESDHC2_WP		IOMUX_PAD(0x810, 0x3E4, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_8__ESDHC2_CD		IOMUX_PAD(0x814, 0x3E8, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)

Some of these are used in 2/9, right? So this patch should be before
2/9.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[patch 1/9] efikamx: read board id

[Sascha Hauer]

On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
> read board id value from the GPIO3_16/17/11
> 
>  
> +/*   PCBID2  PCBID1 PCBID0  STATE
> +	1       1      1    ER1:rev1.1
> +	1       1      0    ER2:rev1.2
> +	1       0      1    ER3:rev1.3
> +	1       0      0    ER4:rev1.4
> +*/
> +static void __init mx51_efikamx_board_id(void)
> +{
> +	int id;
> +
> +	/* things are taking time to settle */
> +	msleep(500);

Is it really necessary to delay the boot process such a long time?

> +
> +	gpio_request(EFIKAMX_PCBID0, "pcbid0");
> +	gpio_direction_input(EFIKAMX_PCBID0);
> +	gpio_request(EFIKAMX_PCBID1, "pcbid1");
> +	gpio_direction_input(EFIKAMX_PCBID1);
> +	gpio_request(EFIKAMX_PCBID2, "pcbid2");
> +	gpio_direction_input(EFIKAMX_PCBID2);
> +
> +	id = gpio_get_value(EFIKAMX_PCBID0);
> +	id |= gpio_get_value(EFIKAMX_PCBID1) << 1;
> +	id |= gpio_get_value(EFIKAMX_PCBID2) << 2;
> +
> +	switch (id) {
> +	case 7:
> +		system_rev = 0x11;
> +		break;
> +	case 6:
> +		system_rev = 0x12;
> +		break;
> +	case 5:
> +		system_rev = 0x13;
> +		break;
> +	case 4:
> +		system_rev = 0x14;
> +		break;
> +	default:
> +		system_rev = 0x10;
> +		break;
> +	}
> +
> +	if	((system_rev == 0x10)

Please replace the tab after 'if' with a space

> +		|| (system_rev == 0x12)
> +		|| (system_rev == 0x14)) {
> +		printk(KERN_WARNING
> +			"EfikaMX: Unsupported board revision 1.%u!\n",
> +			system_rev & 0xf);
> +	}

I know nothing about the versioning scheme, but what about 1.1? Is it
supported?

> +}
> +
>  static void __init mxc_board_init(void)
>  {
>  	mxc_iomux_v3_setup_multiple_pads(mx51efikamx_pads,
>  					ARRAY_SIZE(mx51efikamx_pads));
> +	mx51_efikamx_board_id();
>  	mxc_register_device(&mxc_usbdr_host_device, &dr_utmi_config);
>  	mxc_init_imx_uart();
>  }
> 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[patch 1/9] efikamx: read board id

[Matt Sealey]

On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
>> read board id value from the GPIO3_16/17/11
>>
>>
>> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
>> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
>> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
>> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
>> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
>> +*/
>> +static void __init mx51_efikamx_board_id(void)
>> +{
>> + ? ? int id;
>> +
>> + ? ? /* things are taking time to settle */
>> + ? ? msleep(500);
>
> Is it really necessary to delay the boot process such a long time?

Yes. On older boards the PCBID pins are pulled high by IOMUX settings
(a pulldown on the board on newer revisions will keep it down). IOMUX
and GPIO stuff takes a little while to settle in, so if you do it
immediately, it will return some freakish values based on random GPIO
setup (it may be high, low, or none of the above at any point before
the pad setting kicks in).

>> + ? ? gpio_request(EFIKAMX_PCBID0, "pcbid0");
>> + ? ? gpio_direction_input(EFIKAMX_PCBID0);
>> + ? ? gpio_request(EFIKAMX_PCBID1, "pcbid1");
>> + ? ? gpio_direction_input(EFIKAMX_PCBID1);
>> + ? ? gpio_request(EFIKAMX_PCBID2, "pcbid2");
>> + ? ? gpio_direction_input(EFIKAMX_PCBID2);
>> +
>> + ? ? id = gpio_get_value(EFIKAMX_PCBID0);
>> + ? ? id |= gpio_get_value(EFIKAMX_PCBID1) << 1;
>> + ? ? id |= gpio_get_value(EFIKAMX_PCBID2) << 2;
>> +
>> + ? ? switch (id) {
>> + ? ? case 7:
>> + ? ? ? ? ? ? system_rev = 0x11;
>> + ? ? ? ? ? ? break;
>> + ? ? case 6:
>> + ? ? ? ? ? ? system_rev = 0x12;
>> + ? ? ? ? ? ? break;
>> + ? ? case 5:
>> + ? ? ? ? ? ? system_rev = 0x13;
>> + ? ? ? ? ? ? break;
>> + ? ? case 4:
>> + ? ? ? ? ? ? system_rev = 0x14;
>> + ? ? ? ? ? ? break;
>> + ? ? default:
>> + ? ? ? ? ? ? system_rev = 0x10;
>> + ? ? ? ? ? ? break;
>> + ? ? }
>> +
>> + ? ? if ? ? ?((system_rev == 0x10)
>
> Please replace the tab after 'if' with a space
>
>> + ? ? ? ? ? ? || (system_rev == 0x12)
>> + ? ? ? ? ? ? || (system_rev == 0x14)) {
>> + ? ? ? ? ? ? printk(KERN_WARNING
>> + ? ? ? ? ? ? ? ? ? ? "EfikaMX: Unsupported board revision 1.%u!\n",
>> + ? ? ? ? ? ? ? ? ? ? system_rev & 0xf);
>> + ? ? }
>
> I know nothing about the versioning scheme, but what about 1.1? Is it
> supported?

The check is just a nicety; Genesi have only shipped 1.1 and 1.3
boards to customers.

1.0 was the original "developer edition". Laurent Guerby and a few
other people have these boards to make simple compile farms out of.
Some stuff plain doesn't work, though (ethernet on USB DR port), so we
track it as "unsupported" - if someone wants to fix it up with patches
they may. Until then we warn in dmesg that this is a weird board
revision so we can keep track and warn users not to "complain".

1.1 is the "TO2" original board on sale. They are useful, without
NEON, as compile boxes or so.

1.2 was an internal build featuring most 90% of the features of 1.3,
but with an i.MX515 TO2. They do exist: I have 4 or 5 sitting in my
office. They're pointless to use though as TO2 boards don't have
stable NEON and we didn't do a great deal of testing (1.3 was around
the corner and had fixed a bunch of stuff).

1.3 is the "TO3" board. We shipped it around April/May I think and
customers were offered replacements.

1.4 does not exist in production as of yet (and may not ever be) but
the PCBID is planned already.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

[patch 9/9] efikamx: add reset

[Fabio Estevam]

Hi Arnaud,

--- On Tue, 10/19/10, Arnaud Patard <arnaud.patard@rtp-net.org> wrote:
...
> +void mx51_efikamx_reset(int mode, const char *cmd)
> +{
> +??? if (system_rev == 0x11)
> +??? ???

Couldn't it be void mx51_efikamx_reset(void) instead?

'mode' and 'cmd' are not being used.

Regards,

Fabio Estevam


      

[patch 1/9] efikamx: read board id

[Amit Kucheria]

On 10 Oct 19, Matt Sealey wrote:
> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
> >> read board id value from the GPIO3_16/17/11
> >>
> >>
> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
> >> +*/
> >> +static void __init mx51_efikamx_board_id(void)
> >> +{
> >> + ? ? int id;
> >> +
> >> + ? ? /* things are taking time to settle */
> >> + ? ? msleep(500);
> >
> > Is it really necessary to delay the boot process such a long time?
> 
> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
> (a pulldown on the board on newer revisions will keep it down). IOMUX
> and GPIO stuff takes a little while to settle in, so if you do it
> immediately, it will return some freakish values based on random GPIO
> setup (it may be high, low, or none of the above at any point before
> the pad setting kicks in).

Then perhaps do this only for the older boards?

So by default there is no delay, but when a (new) config option is enabled,
delay boot.

[patch 1/9] efikamx: read board id

[Arnaud Patard (Rtp)]

Amit Kucheria <amit.kucheria@linaro.org> writes:

> On 10 Oct 19, Matt Sealey wrote:
>> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
>> >> read board id value from the GPIO3_16/17/11
>> >>
>> >>
>> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
>> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
>> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
>> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
>> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
>> >> +*/
>> >> +static void __init mx51_efikamx_board_id(void)
>> >> +{
>> >> + ? ? int id;
>> >> +
>> >> + ? ? /* things are taking time to settle */
>> >> + ? ? msleep(500);
>> >
>> > Is it really necessary to delay the boot process such a long time?
>> 
>> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
>> (a pulldown on the board on newer revisions will keep it down). IOMUX
>> and GPIO stuff takes a little while to settle in, so if you do it
>> immediately, it will return some freakish values based on random GPIO
>> setup (it may be high, low, or none of the above at any point before
>> the pad setting kicks in).
>
> Then perhaps do this only for the older boards?

How can you detect older boards without looking at board id pins ? :)

>
> So by default there is no delay, but when a (new) config option is enabled,
> delay boot.

I don't think it's a good idea. This would mean that the same kernel
can't run on old and new boards. Also, there's no way to easily know
which board you have (I don't consider opening the box is an easy way)
so it's likely that someone will get this wrong sooner or later.

Arnaud

[patch 9/9] efikamx: add reset

[Arnaud Patard (Rtp)]

Fabio Estevam <fabioestevam@yahoo.com> writes:

> Hi Arnaud,

Hi,
>
> --- On Tue, 10/19/10, Arnaud Patard <arnaud.patard@rtp-net.org> wrote:
> ...
>> +void mx51_efikamx_reset(int mode, const char *cmd)
>> +{
>> +??? if (system_rev == 0x11)
>> +??? ???
>
> Couldn't it be void mx51_efikamx_reset(void) instead?
>
> 'mode' and 'cmd' are not being used.

I took the same prototype as arch_reset() but I can remove it (and will
do).

Thanks,
Arnaud

[patch 3/9] imx51: enhance/fix iomux configuration

[Arnaud Patard (Rtp)]

Sascha Hauer <s.hauer@pengutronix.de> writes:

Hi,

 >
> Some of these are used in 2/9, right? So this patch should be before
> 2/9.

oh, yeah. sorry. I've reorder the series for some tests and manage to
get this wrong. Will fix.

Arnaud

[patch 1/9] efikamx: read board id

[Sascha Hauer]

On Tue, Oct 19, 2010 at 04:30:25PM -0500, Matt Sealey wrote:
> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
> >> read board id value from the GPIO3_16/17/11
> >>
> >>
> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
> >> +*/
> >> +static void __init mx51_efikamx_board_id(void)
> >> +{
> >> + ? ? int id;
> >> +
> >> + ? ? /* things are taking time to settle */
> >> + ? ? msleep(500);
> >
> > Is it really necessary to delay the boot process such a long time?
> 
> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
> (a pulldown on the board on newer revisions will keep it down). IOMUX
> and GPIO stuff takes a little while to settle in, so if you do it
> immediately, it will return some freakish values based on random GPIO
> setup (it may be high, low, or none of the above at any point before
> the pad setting kicks in).

Maybe it's possible to delay only the registering of the devices which
depend on the board revision, perhaps with a workqueue. But ok, I don't
care much and this won't be a show stopper for this patch.


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[patch 1/9] efikamx: read board id

[Arnaud Patard (Rtp)]

Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Tue, Oct 19, 2010 at 04:30:25PM -0500, Matt Sealey wrote:
>> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
>> >> read board id value from the GPIO3_16/17/11
>> >>
>> >>
>> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
>> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
>> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
>> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
>> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
>> >> +*/
>> >> +static void __init mx51_efikamx_board_id(void)
>> >> +{
>> >> + ? ? int id;
>> >> +
>> >> + ? ? /* things are taking time to settle */
>> >> + ? ? msleep(500);
>> >
>> > Is it really necessary to delay the boot process such a long time?
>> 
>> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
>> (a pulldown on the board on newer revisions will keep it down). IOMUX
>> and GPIO stuff takes a little while to settle in, so if you do it
>> immediately, it will return some freakish values based on random GPIO
>> setup (it may be high, low, or none of the above at any point before
>> the pad setting kicks in).
>
> Maybe it's possible to delay only the registering of the devices which
> depend on the board revision, perhaps with a workqueue. But ok, I don't
> care much and this won't be a show stopper for this patch.

ok. Will wait a little bit more for comments and send a new patchset.

Thanks,
Arnaud

[patch 1/9] efikamx: read board id

[Matt Sealey]

Very few parts of the system require the board id pins to work out the
version. It would be better if the IOMUX was set up and then anything
that requires a flipflop on the board revision is done last. We do
that in the EfikaMX kernels - SDHC and a couple other things rely on
board id but the vast majority of other things (SPI etc.) absolutely
do not.

The time it takes to perform the init of 1 or 2 other units via IOMUX
is time enough to let the PCB id pins settle. This is one of the
reasons we split our board support in our kernels into seperate
files..

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.



On Wed, Oct 20, 2010 at 3:24 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Tue, Oct 19, 2010 at 04:30:25PM -0500, Matt Sealey wrote:
>> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
>> >> read board id value from the GPIO3_16/17/11
>> >>
>> >>
>> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
>> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
>> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
>> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
>> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
>> >> +*/
>> >> +static void __init mx51_efikamx_board_id(void)
>> >> +{
>> >> + ? ? int id;
>> >> +
>> >> + ? ? /* things are taking time to settle */
>> >> + ? ? msleep(500);
>> >
>> > Is it really necessary to delay the boot process such a long time?
>>
>> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
>> (a pulldown on the board on newer revisions will keep it down). IOMUX
>> and GPIO stuff takes a little while to settle in, so if you do it
>> immediately, it will return some freakish values based on random GPIO
>> setup (it may be high, low, or none of the above at any point before
>> the pad setting kicks in).
>
> Maybe it's possible to delay only the registering of the devices which
> depend on the board revision, perhaps with a workqueue. But ok, I don't
> care much and this won't be a show stopper for this patch.
>
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917-5555 |
>

[patch 1/9] efikamx: read board id

[Amit Kucheria]

On 10 Oct 20, Arnaud Patard wrote:
> Amit Kucheria <amit.kucheria@linaro.org> writes:
> 
> > On 10 Oct 19, Matt Sealey wrote:
> >> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
> >> >> read board id value from the GPIO3_16/17/11
> >> >>
> >> >>
> >> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
> >> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
> >> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
> >> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
> >> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
> >> >> +*/
> >> >> +static void __init mx51_efikamx_board_id(void)
> >> >> +{
> >> >> + ? ? int id;
> >> >> +
> >> >> + ? ? /* things are taking time to settle */
> >> >> + ? ? msleep(500);
> >> >
> >> > Is it really necessary to delay the boot process such a long time?
> >> 
> >> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
> >> (a pulldown on the board on newer revisions will keep it down). IOMUX
> >> and GPIO stuff takes a little while to settle in, so if you do it
> >> immediately, it will return some freakish values based on random GPIO
> >> setup (it may be high, low, or none of the above at any point before
> >> the pad setting kicks in).
> >
> > Then perhaps do this only for the older boards?
> 
> How can you detect older boards without looking at board id pins ? :)

You don't. I was suggesting a config option that doesn't penalise those with
non-buggy boards....

> >
> > So by default there is no delay, but when a (new) config option is enabled,
> > delay boot.
> 
> I don't think it's a good idea. This would mean that the same kernel
> can't run on old and new boards. Also, there's no way to easily know
> which board you have (I don't consider opening the box is an easy way)
> so it's likely that someone will get this wrong sooner or later.

...but you're right. If one has to support a variety of boards on single
kernel, this won't work.

/Amit

[patch 3/9] imx51: enhance/fix iomux configuration

[Eric Bénard]

Hi Arnaud,

in this patch, you break configuration for all the GPIO_1_x here (the correct 
lat mux for GPIO mode on pins GPIO_1_x is 1 and not 0).

Eric

[patch 1/9] efikamx: read board id

[Uwe Kleine-König]

Hiho,

On Tue, Oct 19, 2010 at 04:30:25PM -0500, Matt Sealey wrote:
> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
> >> read board id value from the GPIO3_16/17/11
> >>
> >>
> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
> >> +*/
> >> +static void __init mx51_efikamx_board_id(void)
> >> +{
> >> + ? ? int id;
> >> +
> >> + ? ? /* things are taking time to settle */
> >> + ? ? msleep(500);
> >
> > Is it really necessary to delay the boot process such a long time?
> 
> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
> (a pulldown on the board on newer revisions will keep it down). IOMUX
> and GPIO stuff takes a little while to settle in, so if you do it
> immediately, it will return some freakish values based on random GPIO
> setup (it may be high, low, or none of the above at any point before
> the pad setting kicks in).
If the bootloader might configure the pins correctly, maybe something
like:

	if (pins_are_not_yet_configured_correctly()) {
		do_configure_them();
		msleep(500);
	}

?

Best regards
Uwe


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[patch 3/9] imx51: enhance/fix iomux configuration

[Eric Bénard]

Hi Arnaud,

Le 19/10/2010 22:42, Arnaud Patard (Rtp) a ?crit :
 > - ALT0 is used to set GPIO mode of GPIO_1_{2,3,4,5,6,7,8,9} but it's ALT1
for GPIO_1_{0,1}.

oops sorry forget my previous mail, in fact I think I broke 
GPIO_1_{2,3,4,5,6,7,8,9} in a previous patch when fixing GPIO_1_{0,1} :-(
Thanks for noticing and fixing this.

Eric

[patch 3/9] imx51: enhance/fix iomux configuration

[Arnaud Patard (Rtp)]

Eric B?nard <eric@eukrea.com> writes:

> Hi Arnaud,

Hi,
>
> in this patch, you break configuration for all the GPIO_1_x here (the
> correct lat mux for GPIO mode on pins GPIO_1_x is 1 and not 0).

No. For instance, page 3447 of the MCIMX51RM.pdf thing :

000: Select mux mode: ALT0 mux port: GPIO[8] of instance: gpio1.

or page 3441 :

000: Select mux mode: ALT0 mux port: GPIO[3] of instance: gpio1

How is possible that 000b is equal to 1 ?

Arnaud

[patch 3/9] imx51: enhance/fix iomux configuration

[Arnaud Patard (Rtp)]

Eric B?nard <eric@eukrea.com> writes:

> Hi Arnaud,

Hi,

>
> Le 19/10/2010 22:42, Arnaud Patard (Rtp) a ?crit :
>> - ALT0 is used to set GPIO mode of GPIO_1_{2,3,4,5,6,7,8,9} but it's ALT1
> for GPIO_1_{0,1}.
>
> oops sorry forget my previous mail, in fact I think I broke
> GPIO_1_{2,3,4,5,6,7,8,9} in a previous patch when fixing GPIO_1_{0,1}
> :-(

oops. sorry. I've replied too quickly. I've seen this mail after replying.
Please forget my reply then :)

Arnaud

[patch 3/9] imx51: enhance/fix iomux configuration

[Amit Kucheria]

On 10 Oct 20, Eric B?nard wrote:
> Hi Arnaud,
> 
> Le 19/10/2010 22:42, Arnaud Patard (Rtp) a ?crit :
> > - ALT0 is used to set GPIO mode of GPIO_1_{2,3,4,5,6,7,8,9} but it's ALT1
> for GPIO_1_{0,1}.
> 
> oops sorry forget my previous mail, in fact I think I broke
> GPIO_1_{2,3,4,5,6,7,8,9} in a previous patch when fixing
> GPIO_1_{0,1} :-(
> Thanks for noticing and fixing this.

I did wonder where they got flipped from Alt 0 to Alt 1 in the first place.
Just noticed your patch in Sascha's tree.

/Amit

[patch 3/9] imx51: enhance/fix iomux configuration

[Uwe Kleine-König]

On Tue, Oct 19, 2010 at 10:42:56PM +0200, Arnaud Patard wrote:
> - ALT0 is used to set GPIO mode of GPIO_1_{2,3,4,5,6,7,8,9} but it's ALT1
> for GPIO_1_{0,1}.
> - add definition to configure pads as ESDHC{1,2} WP and CD
> 
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> Index: linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h
> ===================================================================
> --- linux-2.6.orig/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:22:06.000000000 +0200
> +++ linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:23:22.000000000 +0200
> @@ -366,20 +366,24 @@
>  							MX51_SDHCI_PAD_CTRL)
>  #define MX51_PAD_SD2_DATA3__SD2_DATA3		IOMUX_PAD(0x7D0, 0x3C8, IOMUX_CONFIG_SION, 0x0, 0, \
>  							MX51_SDHCI_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_0__ESDHC1_CD		IOMUX_PAD(0x7B4, 0x3AC, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
Is MX51_I2C_PAD_CTRL correct?  ditto for MX51_PAD_GPIO_1_1__ESDHC1_WP.

>  #define MX51_PAD_GPIO_1_0__GPIO_1_0		IOMUX_PAD(0x7B4, 0x3AC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_1__ESDHC1_WP		IOMUX_PAD(0x7B8, 0x3B0, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
>  #define MX51_PAD_GPIO_1_1__GPIO_1_1		IOMUX_PAD(0x7B8, 0x3B0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>  #define MX51_PAD_GPIO_1_2__I2C2_SCL		IOMUX_PAD(0x7D4, 0x3CC, (2 | IOMUX_CONFIG_SION), \
>  							0x9b8,   3, MX51_I2C_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>  #define MX51_PAD_GPIO_1_3__I2C2_SDA		IOMUX_PAD(0x7D8, 0x3D0, (2 | IOMUX_CONFIG_SION), \
>  							0x9bc,   3, MX51_I2C_PAD_CTRL)
>  #define MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ	IOMUX_PAD(0x7FC, 0x3D4, 0, 0x0,   0, NO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> -#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_7__ESDHC2_WP		IOMUX_PAD(0x810, 0x3E4, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_8__ESDHC2_CD		IOMUX_PAD(0x814, 0x3E8, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
> +#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
Maybe make this in two patches?  One fix and one to add new definitions?

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[patch 3/9] imx51: enhance/fix iomux configuration

[Arnaud Patard (Rtp)]

Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> writes:

Hi,

> On Tue, Oct 19, 2010 at 10:42:56PM +0200, Arnaud Patard wrote:
>> - ALT0 is used to set GPIO mode of GPIO_1_{2,3,4,5,6,7,8,9} but it's ALT1
>> for GPIO_1_{0,1}.
>> - add definition to configure pads as ESDHC{1,2} WP and CD
>> 
>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>> Index: linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h
>> ===================================================================
>> --- linux-2.6.orig/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:22:06.000000000 +0200
>> +++ linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:23:22.000000000 +0200
>> @@ -366,20 +366,24 @@
>>  							MX51_SDHCI_PAD_CTRL)
>>  #define MX51_PAD_SD2_DATA3__SD2_DATA3		IOMUX_PAD(0x7D0, 0x3C8, IOMUX_CONFIG_SION, 0x0, 0, \
>>  							MX51_SDHCI_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_0__ESDHC1_CD		IOMUX_PAD(0x7B4, 0x3AC, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
> Is MX51_I2C_PAD_CTRL correct?  ditto for MX51_PAD_GPIO_1_1__ESDHC1_WP.

I was about to add something like MX51_ESDHC_PAD_CTRL but it turns out
that according to the original code I have, it would be the same thing
as I2C_PAD_CTRL.

>
>>  #define MX51_PAD_GPIO_1_0__GPIO_1_0		IOMUX_PAD(0x7B4, 0x3AC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_1__ESDHC1_WP		IOMUX_PAD(0x7B8, 0x3B0, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
>>  #define MX51_PAD_GPIO_1_1__GPIO_1_1		IOMUX_PAD(0x7B8, 0x3B0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>>  #define MX51_PAD_GPIO_1_2__I2C2_SCL		IOMUX_PAD(0x7D4, 0x3CC, (2 | IOMUX_CONFIG_SION), \
>>  							0x9b8,   3, MX51_I2C_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>>  #define MX51_PAD_GPIO_1_3__I2C2_SDA		IOMUX_PAD(0x7D8, 0x3D0, (2 | IOMUX_CONFIG_SION), \
>>  							0x9bc,   3, MX51_I2C_PAD_CTRL)
>>  #define MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ	IOMUX_PAD(0x7FC, 0x3D4, 0, 0x0,   0, NO_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> -#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_7__ESDHC2_WP		IOMUX_PAD(0x810, 0x3E4, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_8__ESDHC2_CD		IOMUX_PAD(0x814, 0x3E8, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
>> +#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> Maybe make this in two patches?  One fix and one to add new definitions?

ok. makes sense. will split the patch.

Thanks,
Arnaud

[patch 5/9] efikamx: add leds support

[Amit Kucheria]

On 10 Oct 19, Arnaud Patard wrote:
> The efika mx a 3 leds (1 blue, 1 red, 1 green) connected on GPIOS 3 13/14/15.
> Also, some special care is done for default trigger of blue led for mmc as
> the mmc host used is different between hw revisions
> 
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> 
> Index: linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c
> ===================================================================
> --- linux-2.6.orig/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-15 23:11:42.000000000 +0200
> +++ linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-15 23:11:51.000000000 +0200
> @@ -18,6 +18,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/i2c.h>
>  #include <linux/gpio.h>
> +#include <linux/leds.h>
>  #include <linux/delay.h>
>  #include <linux/io.h>
>  #include <linux/fsl_devices.h>
> @@ -43,6 +44,10 @@
>  #define EFIKAMX_PCBID1		(2*32+17)
>  #define EFIKAMX_PCBID2		(2*32+11)
>  
> +#define EFIKAMX_BLUE_LED	(2*32+13)
> +#define EFIKAMX_GREEN_LED	(2*32+14)
> +#define EFIKAMX_RED_LED		(2*32+15)
> +
>  /* the pci ids pin have pull up. they're driven low according to board id */
>  #define MX51_PAD_PCBID0	IOMUX_PAD(0x518, 0x130, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
>  #define MX51_PAD_PCBID1	IOMUX_PAD(0x51C, 0x134, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
> @@ -81,6 +86,11 @@
>  	MX51_PAD_GPIO_1_1__ESDHC1_WP,
>  	MX51_PAD_GPIO_1_7__ESDHC2_WP,
>  	MX51_PAD_GPIO_1_8__ESDHC2_CD,
> +
> +	/* leds */
> +	MX51_PAD_CSI1_D9__GPIO_3_13,
> +	MX51_PAD_CSI1_VSYNC__GPIO_3_14,
> +	MX51_PAD_CSI1_HSYNC__GPIO_3_15,
>  };
>  
>  /* Serial ports */
> @@ -179,6 +189,37 @@
>  	}
>  }
>  
> +static struct gpio_led mx51_efikamx_leds[] = {
> +	{
> +		.name = "efikamx:green",
> +		.default_trigger = "default-on",
> +		.gpio = EFIKAMX_GREEN_LED,
> +	},
> +	{
> +		.name = "efikamx:red",
> +		.default_trigger = "ide-disk",
> +		.gpio = EFIKAMX_RED_LED,
> +	},
> +	{
> +		.name = "efikamx:blue",
> +		.default_trigger = "mmc1",
> +		.gpio = EFIKAMX_BLUE_LED,

Make the default mmc0 ....

> +	},
> +};
> +
> +static struct gpio_led_platform_data mx51_efikamx_leds_data = {
> +	.leds = mx51_efikamx_leds,
> +	.num_leds = ARRAY_SIZE(mx51_efikamx_leds),
> +};
> +
> +static struct platform_device mx51_efikamx_leds_device = {
> +	.name = "leds-gpio",
> +	.id = -1,
> +	.dev = {
> +		.platform_data = &mx51_efikamx_leds_data,
> +	},
> +};
> +
>  static void __init mxc_board_init(void)
>  {
>  	mxc_iomux_v3_setup_multiple_pads(mx51efikamx_pads,
> @@ -191,6 +232,10 @@
>  	/* on < 1.2 boards the 2 SD controller are used */
>  	if (system_rev < 0x12)
>  		imx51_add_esdhc(1, NULL);
.. and change to mmc1 if system_rev < 0x12. That gets rid of this else
clause below.
>
> +	else
> +		mx51_efikamx_leds[2].default_trigger = "mmc0";
> +	platform_device_register(&mx51_efikamx_leds_device);
>  }
>  
>  static void __init mx51_efikamx_timer_init(void)
> 
> 

[patch 8/9] efikamx: add spi nor support

[Amit Kucheria]

On 10 Oct 19, Arnaud Patard wrote:
> On efikamx, uboot is stored on a nor spi flash. Add support for it
> 
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> Index: linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c
> ===================================================================
> --- linux-2.6.orig/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-16 14:21:24.000000000 +0200
> +++ linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-16 15:34:12.000000000 +0200
> @@ -24,6 +24,8 @@
>  #include <linux/delay.h>
>  #include <linux/io.h>
>  #include <linux/fsl_devices.h>
> +#include <linux/spi/flash.h>
> +#include <linux/spi/spi.h>
>  
>  #include <mach/common.h>
>  #include <mach/hardware.h>
> @@ -52,6 +54,9 @@
>  
>  #define EFIKAMX_POWER_KEY	(1*32+31)
>  
> +#define EFIKAMX_SPI_CS0		(3*32+24)
> +#define EFIKAMX_SPI_CS1		(3*32+25)

It is just a style thing, but could you make this (3*32 + 24). Makes it
easier on the eyes to read "4th gpio bank, 24th pin"

>  /* the pci ids pin have pull up. they're driven low according to board id */
>  #define MX51_PAD_PCBID0	IOMUX_PAD(0x518, 0x130, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
>  #define MX51_PAD_PCBID1	IOMUX_PAD(0x51C, 0x134, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
> @@ -99,6 +104,14 @@
>  
>  	/* power key */
>  	MX51_PAD_PWRKEY,
> +
> +	/* spi */
> +	MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI,
> +	MX51_PAD_CSPI1_MISO__ECSPI1_MISO,
> +	MX51_PAD_CSPI1_SS0__GPIO_4_24,
> +	MX51_PAD_CSPI1_SS1__GPIO_4_25,
> +	MX51_PAD_CSPI1_RDY__ECSPI1_RDY,
> +	MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
>  };
>  
>  /* Serial ports */
> @@ -252,6 +265,47 @@
>  	},
>  };
>  
> +static struct mtd_partition mx51_efikamx_spi_nor_partitions[] = {
> +	{
> +	 .name = "u-boot",

"bootloader" ?

> +	 .offset = 0,
> +	 .size = SZ_256K,
> +	},
> +	{
> +	  .name = "config",
> +	  .offset = MTDPART_OFS_APPEND,
> +	  .size = SZ_64K,
> +	},
> +};
> +
> +static struct flash_platform_data mx51_efikamx_spi_flash_data = {
> +	.name		= "spi_flash",
> +	.parts		= mx51_efikamx_spi_nor_partitions,
> +	.nr_parts	= ARRAY_SIZE(mx51_efikamx_spi_nor_partitions),
> +	.type		= "sst25vf032b",
> +};
> +
> +static struct spi_board_info mx51_efikamx_spi_board_info[] __initdata = {
> +	{
> +		.modalias = "m25p80",
> +		.max_speed_hz = 25000000,
> +		.bus_num = 0,
> +		.chip_select = 1,
> +		.platform_data = &mx51_efikamx_spi_flash_data,
> +		.irq = -1,
> +	},
> +};
> +
> +static int mx51_efikamx_spi_cs[] = {
> +	EFIKAMX_SPI_CS0,
> +	EFIKAMX_SPI_CS1,
> +};
> +
> +static const struct spi_imx_master mx51_efikamx_spi_pdata __initconst = {
> +	.chipselect     = mx51_efikamx_spi_cs,
> +	.num_chipselect = ARRAY_SIZE(mx51_efikamx_spi_cs),
> +};
> +
>  static void __init mxc_board_init(void)
>  {
>  	mxc_iomux_v3_setup_multiple_pads(mx51efikamx_pads,
> @@ -269,6 +323,10 @@
>  
>  	platform_device_register(&mx51_efikamx_leds_device);
>  	platform_device_register(&mx51_efikamx_powerkey_device);
> +
> +	spi_register_board_info(mx51_efikamx_spi_board_info,
> +		ARRAY_SIZE(mx51_efikamx_spi_board_info));
> +	imx51_add_ecspi(0, &mx51_efikamx_spi_pdata);
>  }
>  
>  static void __init mx51_efikamx_timer_init(void)
> Index: linux-2.6/arch/arm/mach-mx5/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/arm/mach-mx5/Kconfig	2010-10-16 14:21:24.000000000 +0200
> +++ linux-2.6/arch/arm/mach-mx5/Kconfig	2010-10-16 14:21:28.000000000 +0200
> @@ -81,6 +81,7 @@
>  	bool "Support MX51 Genesi Efika MX nettop"
>  	select IMX_HAVE_PLATFORM_IMX_UART
>  	select IMX_HAVE_PLATFORM_ESDHC
> +	select IMX_HAVE_PLATFORM_SPI_IMX
>  	help
>  	  Include support for Genesi Efika MX nettop. This includes specific
>  	  configurations for the board and its peripherals.
> 
> 

[patch 8/9] efikamx: add spi nor support

[Arnaud Patard (Rtp)]

Amit Kucheria <amit.kucheria@linaro.org> writes:
Hi,

> On 10 Oct 19, Arnaud Patard wrote:
>> On efikamx, uboot is stored on a nor spi flash. Add support for it
>> 
>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>> Index: linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c
>> ===================================================================
>> --- linux-2.6.orig/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-16 14:21:24.000000000 +0200
>> +++ linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-16 15:34:12.000000000 +0200
>> @@ -24,6 +24,8 @@
>>  #include <linux/delay.h>
>>  #include <linux/io.h>
>>  #include <linux/fsl_devices.h>
>> +#include <linux/spi/flash.h>
>> +#include <linux/spi/spi.h>
>>  
>>  #include <mach/common.h>
>>  #include <mach/hardware.h>
>> @@ -52,6 +54,9 @@
>>  
>>  #define EFIKAMX_POWER_KEY	(1*32+31)
>>  
>> +#define EFIKAMX_SPI_CS0		(3*32+24)
>> +#define EFIKAMX_SPI_CS1		(3*32+25)
>
> It is just a style thing, but could you make this (3*32 + 24). Makes it
> easier on the eyes to read "4th gpio bank, 24th pin"

I've used X*32+Y without space in all patches. So, you prefer that I
change the other places too ?

>
>>  /* the pci ids pin have pull up. they're driven low according to board id */
>>  #define MX51_PAD_PCBID0	IOMUX_PAD(0x518, 0x130, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
>>  #define MX51_PAD_PCBID1	IOMUX_PAD(0x51C, 0x134, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
>> @@ -99,6 +104,14 @@
>>  
>>  	/* power key */
>>  	MX51_PAD_PWRKEY,
>> +
>> +	/* spi */
>> +	MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI,
>> +	MX51_PAD_CSPI1_MISO__ECSPI1_MISO,
>> +	MX51_PAD_CSPI1_SS0__GPIO_4_24,
>> +	MX51_PAD_CSPI1_SS1__GPIO_4_25,
>> +	MX51_PAD_CSPI1_RDY__ECSPI1_RDY,
>> +	MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
>>  };
>>  
>>  /* Serial ports */
>> @@ -252,6 +265,47 @@
>>  	},
>>  };
>>  
>> +static struct mtd_partition mx51_efikamx_spi_nor_partitions[] = {
>> +	{
>> +	 .name = "u-boot",
>
> "bootloader" ?

I don't really mind if it's "u-boot" or "bootloader". It's just a name
after all. Will change to bootloader and if someone disagree, he'll have
to send a new patch imho.

Arnaud

[patch 3/9] imx51: enhance/fix iomux configuration

[Uwe Kleine-König]

On Wed, Oct 20, 2010 at 12:12:30PM +0200, Arnaud Patard wrote:
> Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> writes:
> 
> Hi,
> 
> > On Tue, Oct 19, 2010 at 10:42:56PM +0200, Arnaud Patard wrote:
> >> - ALT0 is used to set GPIO mode of GPIO_1_{2,3,4,5,6,7,8,9} but it's ALT1
> >> for GPIO_1_{0,1}.
> >> - add definition to configure pads as ESDHC{1,2} WP and CD
> >> 
> >> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> >> Index: linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h
> >> ===================================================================
> >> --- linux-2.6.orig/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:22:06.000000000 +0200
> >> +++ linux-2.6/arch/arm/plat-mxc/include/mach/iomux-mx51.h	2010-10-16 22:23:22.000000000 +0200
> >> @@ -366,20 +366,24 @@
> >>  							MX51_SDHCI_PAD_CTRL)
> >>  #define MX51_PAD_SD2_DATA3__SD2_DATA3		IOMUX_PAD(0x7D0, 0x3C8, IOMUX_CONFIG_SION, 0x0, 0, \
> >>  							MX51_SDHCI_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_0__ESDHC1_CD		IOMUX_PAD(0x7B4, 0x3AC, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
> > Is MX51_I2C_PAD_CTRL correct?  ditto for MX51_PAD_GPIO_1_1__ESDHC1_WP.
> 
> I was about to add something like MX51_ESDHC_PAD_CTRL but it turns out
> that according to the original code I have, it would be the same thing
> as I2C_PAD_CTRL.
I'd prefer to have a seperate definition for that.  Using
MX51_I2C_PAD_CTRL looks wrong even if it's correct.
 
> >
> >>  #define MX51_PAD_GPIO_1_0__GPIO_1_0		IOMUX_PAD(0x7B4, 0x3AC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_1__ESDHC1_WP		IOMUX_PAD(0x7B8, 0x3B0, 0, 0x0,   0, MX51_I2C_PAD_CTRL)
> >>  #define MX51_PAD_GPIO_1_1__GPIO_1_1		IOMUX_PAD(0x7B8, 0x3B0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_2__GPIO_1_2		IOMUX_PAD(0x7D4, 0x3CC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >>  #define MX51_PAD_GPIO_1_2__I2C2_SCL		IOMUX_PAD(0x7D4, 0x3CC, (2 | IOMUX_CONFIG_SION), \
> >>  							0x9b8,   3, MX51_I2C_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_3__GPIO_1_3		IOMUX_PAD(0x7D8, 0x3D0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >>  #define MX51_PAD_GPIO_1_3__I2C2_SDA		IOMUX_PAD(0x7D8, 0x3D0, (2 | IOMUX_CONFIG_SION), \
> >>  							0x9bc,   3, MX51_I2C_PAD_CTRL)
> >>  #define MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ	IOMUX_PAD(0x7FC, 0x3D4, 0, 0x0,   0, NO_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> -#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 1, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_4__GPIO_1_4		IOMUX_PAD(0x804, 0x3D8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_5__GPIO_1_5		IOMUX_PAD(0x808, 0x3DC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_6__GPIO_1_6		IOMUX_PAD(0x80C, 0x3E0, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_7__GPIO_1_7		IOMUX_PAD(0x810, 0x3E4, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_7__ESDHC2_WP		IOMUX_PAD(0x810, 0x3E4, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_8__GPIO_1_8		IOMUX_PAD(0x814, 0x3E8, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_8__ESDHC2_CD		IOMUX_PAD(0x814, 0x3E8, 6, 0x0,   0, MX51_I2C_PAD_CTRL)
> >> +#define MX51_PAD_GPIO_1_9__GPIO_1_9		IOMUX_PAD(0x818, 0x3EC, 0, 0x0,   0, MX51_GPIO_PAD_CTRL)
> > Maybe make this in two patches?  One fix and one to add new definitions?
> 
> ok. makes sense. will split the patch.
> 
> Thanks,
> Arnaud
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[patch 8/9] efikamx: add spi nor support

[Amit Kucheria]

On 10 Oct 20, Arnaud Patard wrote:
> Amit Kucheria <amit.kucheria@linaro.org> writes:
> Hi,
> 
> > On 10 Oct 19, Arnaud Patard wrote:
> >> On efikamx, uboot is stored on a nor spi flash. Add support for it
> >> 
> >> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> >> Index: linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c
> >> ===================================================================
> >> --- linux-2.6.orig/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-16 14:21:24.000000000 +0200
> >> +++ linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c	2010-10-16 15:34:12.000000000 +0200
> >> @@ -24,6 +24,8 @@
> >>  #include <linux/delay.h>
> >>  #include <linux/io.h>
> >>  #include <linux/fsl_devices.h>
> >> +#include <linux/spi/flash.h>
> >> +#include <linux/spi/spi.h>
> >>  
> >>  #include <mach/common.h>
> >>  #include <mach/hardware.h>
> >> @@ -52,6 +54,9 @@
> >>  
> >>  #define EFIKAMX_POWER_KEY	(1*32+31)
> >>  
> >> +#define EFIKAMX_SPI_CS0		(3*32+24)
> >> +#define EFIKAMX_SPI_CS1		(3*32+25)
> >
> > It is just a style thing, but could you make this (3*32 + 24). Makes it
> > easier on the eyes to read "4th gpio bank, 24th pin"
> 
> I've used X*32+Y without space in all patches. So, you prefer that I
> change the other places too ?

If you don't mind, yes.

> >
> >>  /* the pci ids pin have pull up. they're driven low according to board id */
> >>  #define MX51_PAD_PCBID0	IOMUX_PAD(0x518, 0x130, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
> >>  #define MX51_PAD_PCBID1	IOMUX_PAD(0x51C, 0x134, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
> >> @@ -99,6 +104,14 @@
> >>  
> >>  	/* power key */
> >>  	MX51_PAD_PWRKEY,
> >> +
> >> +	/* spi */
> >> +	MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI,
> >> +	MX51_PAD_CSPI1_MISO__ECSPI1_MISO,
> >> +	MX51_PAD_CSPI1_SS0__GPIO_4_24,
> >> +	MX51_PAD_CSPI1_SS1__GPIO_4_25,
> >> +	MX51_PAD_CSPI1_RDY__ECSPI1_RDY,
> >> +	MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
> >>  };
> >>  
> >>  /* Serial ports */
> >> @@ -252,6 +265,47 @@
> >>  	},
> >>  };
> >>  
> >> +static struct mtd_partition mx51_efikamx_spi_nor_partitions[] = {
> >> +	{
> >> +	 .name = "u-boot",
> >
> > "bootloader" ?
> 
> I don't really mind if it's "u-boot" or "bootloader". It's just a name
> after all. Will change to bootloader and if someone disagree, he'll have
> to send a new patch imho.

bootloader is a generic term, IMO.

/Amit

[patch 1/9] efikamx: read board id

[Matt Sealey]

Uwe, there is no way to tell if the pads have settled, it is entirely
a hardware problem, just like when GPIOs are at random input states if
they are not connected to anything: in this case, first of all the
IOMUX pull downs and then the GPIO change to input takes longer than
you can safely do it and then immediately read the pins or board
version 1.1 and below will not ID correctly.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.



2010/10/20 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hiho,
>
> On Tue, Oct 19, 2010 at 04:30:25PM -0500, Matt Sealey wrote:
>> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
>> >> read board id value from the GPIO3_16/17/11
>> >>
>> >>
>> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
>> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
>> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
>> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
>> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
>> >> +*/
>> >> +static void __init mx51_efikamx_board_id(void)
>> >> +{
>> >> + ? ? int id;
>> >> +
>> >> + ? ? /* things are taking time to settle */
>> >> + ? ? msleep(500);
>> >
>> > Is it really necessary to delay the boot process such a long time?
>>
>> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
>> (a pulldown on the board on newer revisions will keep it down). IOMUX
>> and GPIO stuff takes a little while to settle in, so if you do it
>> immediately, it will return some freakish values based on random GPIO
>> setup (it may be high, low, or none of the above at any point before
>> the pad setting kicks in).
> If the bootloader might configure the pins correctly, maybe something
> like:
>
> ? ? ? ?if (pins_are_not_yet_configured_correctly()) {
> ? ? ? ? ? ? ? ?do_configure_them();
> ? ? ? ? ? ? ? ?msleep(500);
> ? ? ? ?}
>
> ?
>
> Best regards
> Uwe
>
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Uwe Kleine-K?nig ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>

[patch 8/9] efikamx: add spi nor support

[Matt Sealey]

On Wed, Oct 20, 2010 at 6:26 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> On 10 Oct 19, Arnaud Patard wrote:
>> On efikamx, uboot is stored on a nor spi flash. Add support for it
>>
>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>> Index: linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c
>> ===================================================================
>> --- linux-2.6.orig/arch/arm/mach-mx5/board-mx51_efikamx.c ? ? 2010-10-16 14:21:24.000000000 +0200
>> +++ linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c ?2010-10-16 15:34:12.000000000 +0200
>> @@ -24,6 +24,8 @@
>> ?#include <linux/delay.h>
>> ?#include <linux/io.h>
>> ?#include <linux/fsl_devices.h>
>> +#include <linux/spi/flash.h>
>> +#include <linux/spi/spi.h>
>>
>> ?#include <mach/common.h>
>> ?#include <mach/hardware.h>
>> @@ -52,6 +54,9 @@
>>
>> ?#define EFIKAMX_POWER_KEY ? ?(1*32+31)
>>
>> +#define EFIKAMX_SPI_CS0 ? ? ? ? ? ? ?(3*32+24)
>> +#define EFIKAMX_SPI_CS1 ? ? ? ? ? ? ?(3*32+25)
>
> It is just a style thing, but could you make this (3*32 + 24). Makes it
> easier on the eyes to read "4th gpio bank, 24th pin"

Better yet:

#define GPIO_BANK(n) ((n-1)*32)
..
#define EFIKAMX_SPI_CS0 (GPIO_BANK(4) + 24).

It'll get compiled to a constant and is more readable, right? :D

>> ?/* the pci ids pin have pull up. they're driven low according to board id */
>> ?#define MX51_PAD_PCBID0 ? ? ?IOMUX_PAD(0x518, 0x130, 3, 0x0, ? 0, PAD_CTL_PUS_100K_UP)
>> ?#define MX51_PAD_PCBID1 ? ? ?IOMUX_PAD(0x51C, 0x134, 3, 0x0, ? 0, PAD_CTL_PUS_100K_UP)
>> @@ -99,6 +104,14 @@
>>
>> ? ? ? /* power key */
>> ? ? ? MX51_PAD_PWRKEY,
>> +
>> + ? ? /* spi */
>> + ? ? MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI,
>> + ? ? MX51_PAD_CSPI1_MISO__ECSPI1_MISO,
>> + ? ? MX51_PAD_CSPI1_SS0__GPIO_4_24,
>> + ? ? MX51_PAD_CSPI1_SS1__GPIO_4_25,
>> + ? ? MX51_PAD_CSPI1_RDY__ECSPI1_RDY,
>> + ? ? MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
>> ?};
>>
>> ?/* Serial ports */
>> @@ -252,6 +265,47 @@
>> ? ? ? },
>> ?};
>>
>> +static struct mtd_partition mx51_efikamx_spi_nor_partitions[] = {
>> + ? ? {
>> + ? ? ?.name = "u-boot",
>
> "bootloader" ?

"firmware" :)

-- 
Matt

[patch 8/9] efikamx: add spi nor support

[Arnaud Patard (Rtp)]

Matt Sealey <matt@genesi-usa.com> writes:

> On Wed, Oct 20, 2010 at 6:26 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>> On 10 Oct 19, Arnaud Patard wrote:
>>> On efikamx, uboot is stored on a nor spi flash. Add support for it
>>>
>>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>>> Index: linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c
>>> ===================================================================
>>> --- linux-2.6.orig/arch/arm/mach-mx5/board-mx51_efikamx.c ? ? 2010-10-16 14:21:24.000000000 +0200
>>> +++ linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c ?2010-10-16 15:34:12.000000000 +0200
>>> @@ -24,6 +24,8 @@
>>> ?#include <linux/delay.h>
>>> ?#include <linux/io.h>
>>> ?#include <linux/fsl_devices.h>
>>> +#include <linux/spi/flash.h>
>>> +#include <linux/spi/spi.h>
>>>
>>> ?#include <mach/common.h>
>>> ?#include <mach/hardware.h>
>>> @@ -52,6 +54,9 @@
>>>
>>> ?#define EFIKAMX_POWER_KEY ? ?(1*32+31)
>>>
>>> +#define EFIKAMX_SPI_CS0 ? ? ? ? ? ? ?(3*32+24)
>>> +#define EFIKAMX_SPI_CS1 ? ? ? ? ? ? ?(3*32+25)
>>
>> It is just a style thing, but could you make this (3*32 + 24). Makes it
>> easier on the eyes to read "4th gpio bank, 24th pin"
>
> Better yet:
>
> #define GPIO_BANK(n) ((n-1)*32)
> ..
> #define EFIKAMX_SPI_CS0 (GPIO_BANK(4) + 24).
>
> It'll get compiled to a constant and is more readable, right? :D

you can even imagine something like
#define MX51_GPIO(x,y)         ((x-1) + y)

Anyway, imho it should be a different patch because if we're going this
way all imx51 machines files would deserve the same change.

>
>>> ?/* the pci ids pin have pull up. they're driven low according to board id */
>>> ?#define MX51_PAD_PCBID0 ? ? ?IOMUX_PAD(0x518, 0x130, 3, 0x0, ? 0, PAD_CTL_PUS_100K_UP)
>>> ?#define MX51_PAD_PCBID1 ? ? ?IOMUX_PAD(0x51C, 0x134, 3, 0x0, ? 0, PAD_CTL_PUS_100K_UP)
>>> @@ -99,6 +104,14 @@
>>>
>>> ? ? ? /* power key */
>>> ? ? ? MX51_PAD_PWRKEY,
>>> +
>>> + ? ? /* spi */
>>> + ? ? MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI,
>>> + ? ? MX51_PAD_CSPI1_MISO__ECSPI1_MISO,
>>> + ? ? MX51_PAD_CSPI1_SS0__GPIO_4_24,
>>> + ? ? MX51_PAD_CSPI1_SS1__GPIO_4_25,
>>> + ? ? MX51_PAD_CSPI1_RDY__ECSPI1_RDY,
>>> + ? ? MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
>>> ?};
>>>
>>> ?/* Serial ports */
>>> @@ -252,6 +265,47 @@
>>> ? ? ? },
>>> ?};
>>>
>>> +static struct mtd_partition mx51_efikamx_spi_nor_partitions[] = {
>>> + ? ? {
>>> + ? ? ?.name = "u-boot",
>>
>> "bootloader" ?
>
> "firmware" :)

please, reach an agreement with Amit. I don't want to be blocked by such
a thing :)

Arnaud

[patch 1/9] efikamx: read board id

[Loïc Minier]

On Wed, Oct 20, 2010, Matt Sealey wrote:
> Uwe, there is no way to tell if the pads have settled, it is entirely
> a hardware problem, just like when GPIOs are at random input states if
> they are not connected to anything: in this case, first of all the
> IOMUX pull downs and then the GPIO change to input takes longer than
> you can safely do it and then immediately read the pins or board
> version 1.1 and below will not ID correctly.

 Is there a strong need to distinguish between all the PCB ids?  You
 could use the TO2 versus TO3 information to decide between 1.1 and 1.3
 PCBs and stop supporting the other (rare) boards?

-- 
Lo?c Minier

[patch 1/9] efikamx: read board id

[Arnaud Patard (Rtp)]

Lo?c Minier <loic.minier@linaro.org> writes:

> On Wed, Oct 20, 2010, Matt Sealey wrote:
>> Uwe, there is no way to tell if the pads have settled, it is entirely
>> a hardware problem, just like when GPIOs are at random input states if
>> they are not connected to anything: in this case, first of all the
>> IOMUX pull downs and then the GPIO change to input takes longer than
>> you can safely do it and then immediately read the pins or board
>> version 1.1 and below will not ID correctly.
>
>  Is there a strong need to distinguish between all the PCB ids?  You
>  could use the TO2 versus TO3 information to decide between 1.1 and 1.3
>  PCBs and stop supporting the other (rare) boards?

The TO2 and TO3 are very similar but there are important differencies :
- different reset pin
- mmc slot on mmc0 (esdhci1) vs mmc1 (esdhci2)

So you do need to know if you're either on TO2 or TO3 and you can't
guess this info without looking at the board id pins.

Arnaud

[patch 8/9] efikamx: add spi nor support

[Matt Sealey]

I like "u-boot" better as it's descriptive. If we flash a different firmware it might be redboot or aura or barebox or openbios and the partitioning should reflect that... Hopefully based on a device tree or residual data from the firmware itself. For now, "u-boot" is okay in my book

Matt Sealey
Product Development Analyst
Genesi USA, Inc.

On Oct 20, 2010, at 12:55 PM, Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> wrote:

> Matt Sealey <matt@genesi-usa.com> writes:
> 
>> On Wed, Oct 20, 2010 at 6:26 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>>> On 10 Oct 19, Arnaud Patard wrote:
>>>> On efikamx, uboot is stored on a nor spi flash. Add support for it
>>>> 
>>>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>>>> Index: linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c
>>>> ===================================================================
>>>> --- linux-2.6.orig/arch/arm/mach-mx5/board-mx51_efikamx.c     2010-10-16 14:21:24.000000000 +0200
>>>> +++ linux-2.6/arch/arm/mach-mx5/board-mx51_efikamx.c  2010-10-16 15:34:12.000000000 +0200
>>>> @@ -24,6 +24,8 @@
>>>>  #include <linux/delay.h>
>>>>  #include <linux/io.h>
>>>>  #include <linux/fsl_devices.h>
>>>> +#include <linux/spi/flash.h>
>>>> +#include <linux/spi/spi.h>
>>>> 
>>>>  #include <mach/common.h>
>>>>  #include <mach/hardware.h>
>>>> @@ -52,6 +54,9 @@
>>>> 
>>>>  #define EFIKAMX_POWER_KEY    (1*32+31)
>>>> 
>>>> +#define EFIKAMX_SPI_CS0              (3*32+24)
>>>> +#define EFIKAMX_SPI_CS1              (3*32+25)
>>> 
>>> It is just a style thing, but could you make this (3*32 + 24). Makes it
>>> easier on the eyes to read "4th gpio bank, 24th pin"
>> 
>> Better yet:
>> 
>> #define GPIO_BANK(n) ((n-1)*32)
>> ..
>> #define EFIKAMX_SPI_CS0 (GPIO_BANK(4) + 24).
>> 
>> It'll get compiled to a constant and is more readable, right? :D
> 
> you can even imagine something like
> #define MX51_GPIO(x,y)         ((x-1) + y)
> 
> Anyway, imho it should be a different patch because if we're going this
> way all imx51 machines files would deserve the same change.
> 
>> 
>>>>  /* the pci ids pin have pull up. they're driven low according to board id */
>>>>  #define MX51_PAD_PCBID0      IOMUX_PAD(0x518, 0x130, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
>>>>  #define MX51_PAD_PCBID1      IOMUX_PAD(0x51C, 0x134, 3, 0x0,   0, PAD_CTL_PUS_100K_UP)
>>>> @@ -99,6 +104,14 @@
>>>> 
>>>>       /* power key */
>>>>       MX51_PAD_PWRKEY,
>>>> +
>>>> +     /* spi */
>>>> +     MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI,
>>>> +     MX51_PAD_CSPI1_MISO__ECSPI1_MISO,
>>>> +     MX51_PAD_CSPI1_SS0__GPIO_4_24,
>>>> +     MX51_PAD_CSPI1_SS1__GPIO_4_25,
>>>> +     MX51_PAD_CSPI1_RDY__ECSPI1_RDY,
>>>> +     MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
>>>>  };
>>>> 
>>>>  /* Serial ports */
>>>> @@ -252,6 +265,47 @@
>>>>       },
>>>>  };
>>>> 
>>>> +static struct mtd_partition mx51_efikamx_spi_nor_partitions[] = {
>>>> +     {
>>>> +      .name = "u-boot",
>>> 
>>> "bootloader" ?
>> 
>> "firmware" :)
> 
> please, reach an agreement with Amit. I don't want to be blocked by such
> a thing :)
> 
> Arnaud

[patch 1/9] efikamx: read board id

[Matt Sealey]

No like I said several boards will work with the code as the pcb design has changed. I am sure the few people with 1.0 boards would like to run 2.6.36 too.

It's just about decoupling the setting of the pins and reporting the board id. Set the board id pins up first. Then do some other stuff. Then go back before you need it, and set system_rev up.

Matt Sealey
Product Development Analyst
Genesi USA, Inc.

On Oct 20, 2010, at 2:26 PM, Lo?c Minier <loic.minier@linaro.org> wrote:

> On Wed, Oct 20, 2010, Matt Sealey wrote:
>> Uwe, there is no way to tell if the pads have settled, it is entirely
>> a hardware problem, just like when GPIOs are at random input states if
>> they are not connected to anything: in this case, first of all the
>> IOMUX pull downs and then the GPIO change to input takes longer than
>> you can safely do it and then immediately read the pins or board
>> version 1.1 and below will not ID correctly.
> 
> Is there a strong need to distinguish between all the PCB ids?  You
> could use the TO2 versus TO3 information to decide between 1.1 and 1.3
> PCBs and stop supporting the other (rare) boards?
> 
> -- 
> Lo?c Minier

[patch 1/9] efikamx: read board id

[Matt Sealey]

On Wed, Oct 20, 2010 at 2:53 PM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
>
> The TO2 and TO3 are very similar but there are important differencies :
> - different reset pin
> - mmc slot on mmc0 (esdhci1) vs mmc1 (esdhci2)

Actually the 1.1 boards have two SD card slots (one is inside under
the lid, MicroSD) and the differentiation is merely so that the front
slot always gets the LED activity (it's more useful to users to know
that the SD card they inserted is doing stuff than the magic one
behind 9 screws that you need to dismantle the case to get to..)

> So you do need to know if you're either on TO2 or TO3 and you can't
> guess this info without looking at the board id pins.

Ideally the board id pins would be implemented on all revisions of the
board, but since they are not there on 1.0 and 1.1 (and the IOMUX
takes time to settle to pretend they are there with pullups/pulldowns)
this is the hard cause of the problem. However, reading board id pins
right after IOMUX is going to cause random results on any board.

Check the Genesi git tree (arch/arm/mach-mx5/mx51_efikamx_io.c) and
you'll see how we split this up to basically set up the pins, do other
things, THEN find out the board id. The similarities mean you can go
and do a bunch of other stuff while you are waiting for the IOMUX to
settle, and by that time it will be done. While that time is not
exactly deterministic, it is certainly not 500ms, we used to have a
delay of 100ms just to be very very sure, and then just split it out
and it works just as well.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.