[U-Boot] [PATCH 0/6] eSDHC/DR USB switching on MPC837X boards

[U-Boot] [PATCH 0/6] eSDHC/DR USB switching on MPC837X boards

[Anton Vorontsov]

Hi all,

Because of pin multiplexing the eSDHC and DR USB are mutually
exclusive on MPC837X processors, so we have to support switching
between the two devices, and properly fixup the device tree.

Patches on the way...

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 1/6] fdt_support, usb: Move fdt_fixup_dr_usb() routine to drivers/usb/

[Anton Vorontsov]

In subsequent patches we'll use FSL-specific functions in
fdt_fixup_dr_usb(), so let's move the routine to a more appropriate
place.

So far fsl_dr_usb.c isn't actually an USB driver, but eventually it
will turn into one, let's hope. ;-)

Also rename CONFIG_HAS_FSL_DR_USB to CONFIG_USB_FSL_DR to be
consistent with other USB drivers.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 board/freescale/mpc8315erdb/mpc8315erdb.c |    1 +
 board/freescale/mpc837xemds/mpc837xemds.c |    1 +
 board/freescale/mpc837xerdb/mpc837xerdb.c |    1 +
 common/fdt_support.c                      |   41 ----------------------
 drivers/usb/Makefile                      |    1 +
 drivers/usb/fsl_dr_usb.c                  |   52 +++++++++++++++++++++++++++++
 include/configs/MPC8315ERDB.h             |    2 +-
 include/configs/MPC837XEMDS.h             |    2 +-
 include/configs/MPC837XERDB.h             |    2 +-
 include/fdt_support.h                     |    6 ---
 include/fsl_dr_usb.h                      |   21 +++++++++++
 11 files changed, 80 insertions(+), 50 deletions(-)
 create mode 100644 drivers/usb/fsl_dr_usb.c
 create mode 100644 include/fsl_dr_usb.h

diff --git a/board/freescale/mpc8315erdb/mpc8315erdb.c b/board/freescale/mpc8315erdb/mpc8315erdb.c
index f80b0ba..9d6896d 100644
--- a/board/freescale/mpc8315erdb/mpc8315erdb.c
+++ b/board/freescale/mpc8315erdb/mpc8315erdb.c
@@ -30,6 +30,7 @@
 #include <pci.h>
 #include <mpc83xx.h>
 #include <netdev.h>
+#include <fsl_dr_usb.h>
 #include <asm/io.h>
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/board/freescale/mpc837xemds/mpc837xemds.c b/board/freescale/mpc837xemds/mpc837xemds.c
index 062d762..376b7f2 100644
--- a/board/freescale/mpc837xemds/mpc837xemds.c
+++ b/board/freescale/mpc837xemds/mpc837xemds.c
@@ -18,6 +18,7 @@
 #include <tsec.h>
 #include <libfdt.h>
 #include <fdt_support.h>
+#include <fsl_dr_usb.h>
 #include "pci.h"
 #include "../common/pq-mds-pib.h"
 
diff --git a/board/freescale/mpc837xerdb/mpc837xerdb.c b/board/freescale/mpc837xerdb/mpc837xerdb.c
index 318a3dc..8cbac14 100644
--- a/board/freescale/mpc837xerdb/mpc837xerdb.c
+++ b/board/freescale/mpc837xerdb/mpc837xerdb.c
@@ -19,6 +19,7 @@
 #include <fdt_support.h>
 #include <spd_sdram.h>
 #include <vsc7385.h>
+#include <fsl_dr_usb.h>
 
 #if defined(CONFIG_SYS_DRAM_TEST)
 int
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b54f886..ec6cff1 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -454,47 +454,6 @@ void fdt_fixup_ethernet(void *fdt)
 	}
 }
 
-#ifdef CONFIG_HAS_FSL_DR_USB
-void fdt_fixup_dr_usb(void *blob, bd_t *bd)
-{
-	char *mode;
-	char *type;
-	const char *compat = "fsl-usb2-dr";
-	const char *prop_mode = "dr_mode";
-	const char *prop_type = "phy_type";
-	int node_offset;
-	int err;
-
-	mode = getenv("usb_dr_mode");
-	type = getenv("usb_phy_type");
-	if (!mode && !type)
-		return;
-
-	node_offset = fdt_node_offset_by_compatible(blob, 0, compat);
-	if (node_offset < 0) {
-		printf("WARNING: could not find compatible node %s: %s.\n",
-			compat, fdt_strerror(node_offset));
-		return;
-	}
-
-	if (mode) {
-		err = fdt_setprop(blob, node_offset, prop_mode, mode,
-				  strlen(mode) + 1);
-		if (err < 0)
-			printf("WARNING: could not set %s for %s: %s.\n",
-			       prop_mode, compat, fdt_strerror(err));
-	}
-
-	if (type) {
-		err = fdt_setprop(blob, node_offset, prop_type, type,
-				  strlen(type) + 1);
-		if (err < 0)
-			printf("WARNING: could not set %s for %s: %s.\n",
-			       prop_type, compat, fdt_strerror(err));
-	}
-}
-#endif /* CONFIG_HAS_FSL_DR_USB */
-
 #if defined(CONFIG_MPC83XX) || defined(CONFIG_MPC85xx)
 /*
  * update crypto node properties to a specified revision of the SEC
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index b306a65..bb71a26 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_USB_EHCI_IXP4XX) += usb_ehci_ixp.o
 COBJS-$(CONFIG_MUSB_HCD) += musb_hcd.o musb_core.o
 COBJS-$(CONFIG_USB_DAVINCI) += davinci_usb.o
 COBJS-$(CONFIG_USB_EHCI_VCT) += usb_ehci_vct.o
+COBJS-$(CONFIG_USB_FSL_DR) += fsl_dr_usb.o
 
 # device
 ifdef CONFIG_USB_DEVICE
diff --git a/drivers/usb/fsl_dr_usb.c b/drivers/usb/fsl_dr_usb.c
new file mode 100644
index 0000000..af9797f
--- /dev/null
+++ b/drivers/usb/fsl_dr_usb.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2008-2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * 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.
+ */
+
+#include <common.h>
+#include <libfdt.h>
+
+void fdt_fixup_dr_usb(void *blob, bd_t *bd)
+{
+	char *mode;
+	char *type;
+	const char *compat = "fsl-usb2-dr";
+	const char *prop_mode = "dr_mode";
+	const char *prop_type = "phy_type";
+	int node_offset;
+	int err;
+
+	mode = getenv("usb_dr_mode");
+	type = getenv("usb_phy_type");
+	if (!mode && !type)
+		return;
+
+	node_offset = fdt_node_offset_by_compatible(blob, 0, compat);
+	if (node_offset < 0) {
+		printf("WARNING: could not find compatible node %s: %s.\n",
+			compat, fdt_strerror(node_offset));
+		return;
+	}
+
+	if (mode) {
+		err = fdt_setprop(blob, node_offset, prop_mode, mode,
+				  strlen(mode) + 1);
+		if (err < 0)
+			printf("WARNING: could not set %s for %s: %s.\n",
+			       prop_mode, compat, fdt_strerror(err));
+	}
+
+	if (type) {
+		err = fdt_setprop(blob, node_offset, prop_type, type,
+				  strlen(type) + 1);
+		if (err < 0)
+			printf("WARNING: could not set %s for %s: %s.\n",
+			       prop_type, compat, fdt_strerror(err));
+	}
+}
diff --git a/include/configs/MPC8315ERDB.h b/include/configs/MPC8315ERDB.h
index 9fa91f4..e3dcf96 100644
--- a/include/configs/MPC8315ERDB.h
+++ b/include/configs/MPC8315ERDB.h
@@ -344,7 +344,7 @@
 #define CONFIG_NET_MULTI	1
 #endif
 
-#define CONFIG_HAS_FSL_DR_USB
+#define CONFIG_USB_FSL_DR	1
 
 /*
  * TSEC
diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
index a62d805..68e0239 100644
--- a/include/configs/MPC837XEMDS.h
+++ b/include/configs/MPC837XEMDS.h
@@ -384,7 +384,7 @@ extern int board_pci_host_broken(void);
 #define CONFIG_83XX_GENERIC_PCIE	1
 #define CONFIG_PQ_MDS_PIB	1 /* PQ MDS Platform IO Board */
 
-#define CONFIG_HAS_FSL_DR_USB	1 /* fixup device tree for the DR USB */
+#define CONFIG_USB_FSL_DR	1 /* fixup device tree for the DR USB */
 
 #define CONFIG_NET_MULTI
 #define CONFIG_PCI_PNP		/* do pci plug-and-play */
diff --git a/include/configs/MPC837XERDB.h b/include/configs/MPC837XERDB.h
index 8d0c93b..df7e746 100644
--- a/include/configs/MPC837XERDB.h
+++ b/include/configs/MPC837XERDB.h
@@ -638,7 +638,7 @@
 #define CONFIG_ETH1ADDR		00:04:9f:ef:04:02
 #endif
 
-#define CONFIG_HAS_FSL_DR_USB
+#define CONFIG_USB_FSL_DR	1
 
 #define CONFIG_IPADDR		10.0.0.2
 #define CONFIG_SERVERIP		10.0.0.1
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 6062df9..7ee29ef 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -53,12 +53,6 @@ int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
 			 const void *val, int len, int create);
 void fdt_fixup_qe_firmware(void *fdt);
 
-#ifdef CONFIG_HAS_FSL_DR_USB
-void fdt_fixup_dr_usb(void *blob, bd_t *bd);
-#else
-static inline void fdt_fixup_dr_usb(void *blob, bd_t *bd) {}
-#endif /* CONFIG_HAS_FSL_DR_USB */
-
 #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC83XX)
 void fdt_fixup_crypto_node(void *blob, int sec_rev);
 #else
diff --git a/include/fsl_dr_usb.h b/include/fsl_dr_usb.h
new file mode 100644
index 0000000..c14d9ba
--- /dev/null
+++ b/include/fsl_dr_usb.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2008-2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * 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.
+ */
+
+#ifndef __DR_USB_H
+#define __DR_USB_H
+
+#ifdef CONFIG_USB_FSL_DR
+void fdt_fixup_dr_usb(void *blob, bd_t *bd);
+#else
+static inline void fdt_fixup_dr_usb(void *blob, bd_t *bd) {}
+#endif
+
+#endif /* __DR_USB_H */
-- 
1.5.6.5

[U-Boot] [PATCH 1/6] fdt_support, usb: Move fdt_fixup_dr_usb() routine to drivers/usb/

[Jerry Van Baren]

Anton Vorontsov wrote:
> In subsequent patches we'll use FSL-specific functions in
> fdt_fixup_dr_usb(), so let's move the routine to a more appropriate
> place.
> 
> So far fsl_dr_usb.c isn't actually an USB driver, but eventually it
> will turn into one, let's hope. ;-)
> 
> Also rename CONFIG_HAS_FSL_DR_USB to CONFIG_USB_FSL_DR to be
> consistent with other USB drivers.
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>  board/freescale/mpc8315erdb/mpc8315erdb.c |    1 +
>  board/freescale/mpc837xemds/mpc837xemds.c |    1 +
>  board/freescale/mpc837xerdb/mpc837xerdb.c |    1 +
>  common/fdt_support.c                      |   41 ----------------------
>  drivers/usb/Makefile                      |    1 +
>  drivers/usb/fsl_dr_usb.c                  |   52 +++++++++++++++++++++++++++++
>  include/configs/MPC8315ERDB.h             |    2 +-
>  include/configs/MPC837XEMDS.h             |    2 +-
>  include/configs/MPC837XERDB.h             |    2 +-
>  include/fdt_support.h                     |    6 ---
>  include/fsl_dr_usb.h                      |   21 +++++++++++
>  11 files changed, 80 insertions(+), 50 deletions(-)
>  create mode 100644 drivers/usb/fsl_dr_usb.c
>  create mode 100644 include/fsl_dr_usb.h

Hi Anton,

I presume you CC:ed me on this series because fdt_support.c is involved. 
  I view this as more of a board/processor issue than a libfdt issue: 
I'm happy to ack the concept, but leave it to Kim/Andy/Kumar to do the 
dirty work.

Thanks,
gvb

[U-Boot] [PATCH 2/6] Add FSL "Can use" framework

[Anton Vorontsov]

So far it's used for specifying whether we want to use FSL DR USB or
FSL eSDHC devices on MPC837X processors.

There are two more candidates for future use:
1. USB ULPI PHY vs. TSEC1 on MPC8315E-RDB boards;
2. Marvell vs. Vitesse PHYs on MPC8313E-RDB boards.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 board/freescale/common/Makefile      |    1 +
 board/freescale/common/fsl_can_use.c |   30 ++++++++++++++++++++++++++++++
 include/fsl_can_use.h                |   32 ++++++++++++++++++++++++++++++++
 3 files changed, 63 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/common/fsl_can_use.c
 create mode 100644 include/fsl_can_use.h

diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 02a824d..d4e2009 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -29,6 +29,7 @@ endif
 
 LIB	= $(obj)lib$(VENDOR).a
 
+COBJS-y				+= fsl_can_use.o
 COBJS-${CONFIG_FSL_CADMUS}	+= cadmus.o
 COBJS-${CONFIG_FSL_VIA}		+= cds_via.o
 COBJS-${CONFIG_FSL_DIU_FB}	+= fsl_diu_fb.o fsl_logo_bmp.o
diff --git a/board/freescale/common/fsl_can_use.c b/board/freescale/common/fsl_can_use.c
new file mode 100644
index 0000000..17cc20f
--- /dev/null
+++ b/board/freescale/common/fsl_can_use.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * 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.
+ */
+
+#include <common.h>
+
+#if defined(CONFIG_MPC837X) && defined(CONFIG_USB_FSL_DR) && \
+		defined(CONFIG_FSL_ESDHC)
+int __fsl_can_use_dr_usb(void)
+{
+	const char *usb_or_esdhc = getenv("usb_or_esdhc");
+
+	if (!usb_or_esdhc || !strcmp(usb_or_esdhc, "usb"))
+		return 1;
+
+	if (!strcmp(usb_or_esdhc, "esdhc"))
+		return 0;
+
+	printf("WARNING: Wrong value for `usb_or_esdhc' environment variable: "
+	       "`%s', should be `usb' (default) or `esdhc'\n", usb_or_esdhc);
+	return 1;
+}
+#endif
diff --git a/include/fsl_can_use.h b/include/fsl_can_use.h
new file mode 100644
index 0000000..932bbc1
--- /dev/null
+++ b/include/fsl_can_use.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * 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.
+ */
+
+#ifndef __FSL_CAN_USE_H
+#define __FSL_CAN_USE_H
+
+#if defined(CONFIG_MPC837X) && defined(CONFIG_USB_FSL_DR) && \
+		defined(CONFIG_FSL_ESDHC)
+extern int __fsl_can_use_dr_usb(void);
+#define fsl_can_use_dr_usb __fsl_can_use_dr_usb
+
+static inline int __fsl_can_use_esdhc(void) { return !fsl_can_use_dr_usb(); }
+#define fsl_can_use_esdhc __fsl_can_use_esdhc
+#endif /* CONFIG_MPC837X && CONFIG_USB_FSL_DR && CONFIG_FSL_ESDHC */
+
+#ifndef fsl_can_use_dr_usb
+#define fsl_can_use_dr_usb() 1
+#endif
+
+#ifndef fsl_can_use_esdhc
+#define fsl_can_use_esdhc() 1
+#endif
+
+#endif /* __FSL_CAN_USE_H */
-- 
1.5.6.5

[U-Boot] [PATCH 2/6] Add FSL "Can use" framework

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090219154545.GB26618@oksana.dev.rtsoft.ru> you wrote:
> So far it's used for specifying whether we want to use FSL DR USB or
> FSL eSDHC devices on MPC837X processors.
> 
> There are two more candidates for future use:
> 1. USB ULPI PHY vs. TSEC1 on MPC8315E-RDB boards;
> 2. Marvell vs. Vitesse PHYs on MPC8313E-RDB boards.

If you know that might need to be extended, than better plan for it
right from the beginning.

> diff --git a/board/freescale/common/fsl_can_use.c b/board/freescale/common/fsl_can_use.c
> new file mode 100644
> index 0000000..17cc20f
> --- /dev/null
> +++ b/board/freescale/common/fsl_can_use.c

That's a very strange name for a function, IMHO. I would expect that
it has something to do with using a CAN controller...

> +int __fsl_can_use_dr_usb(void)

If you plan to make this extendable, please use a more generic name.
For example: fsl_hwconfig() [note that leading __ is reserved].

> +	const char *usb_or_esdhc = getenv("usb_or_esdhc");

Please make it extendable, use a more generic name for one (and only
one) environment variable. It makes littel sense to pollyte the
envrionment with N additional variables. For example, call it
"hwconfig". Allow that this variable holds a list of config settings,
separated for example by comma or colon or ...

> +	if (!usb_or_esdhc || !strcmp(usb_or_esdhc, "usb"))
> +		return 1;
> +
> +	if (!strcmp(usb_or_esdhc, "esdhc"))
> +		return 0;

This doesn't scale as well. Use a table of known strings and (static
inline) function pointers - this is much easier to extend when new
options need to get added.


Once we've reached this point, we might even lean back and think which
part of this is FSL specific. None, tight? So make this a generic
feature and look around which other code can be replaced by it.

We can probably define both the content of option name / handler
function pointer table and the respective handler functions in a board
specific file - eventually even the board config file.

That would make for a flexible solution.

> +extern int __fsl_can_use_dr_usb(void);
> +#define fsl_can_use_dr_usb __fsl_can_use_dr_usb
> +
> +static inline int __fsl_can_use_esdhc(void) { return !fsl_can_use_dr_usb(); }
> +#define fsl_can_use_esdhc __fsl_can_use_esdhc

Do we really need such cryptic code? Please clean up!

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: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.

[U-Boot] [PATCH 2/6] Add FSL "Can use" framework

[Kim Phillips]

On Thu, 19 Feb 2009 20:56:50 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Anton Vorontsov,
> 
> In message <20090219154545.GB26618@oksana.dev.rtsoft.ru> you wrote:
> > So far it's used for specifying whether we want to use FSL DR USB or
> > FSL eSDHC devices on MPC837X processors.
> > 
> > There are two more candidates for future use:
> > 1. USB ULPI PHY vs. TSEC1 on MPC8315E-RDB boards;
> > 2. Marvell vs. Vitesse PHYs on MPC8313E-RDB boards.

Isn't the marvell PHY detectable by s/w?

> > +	const char *usb_or_esdhc = getenv("usb_or_esdhc");
> 
> Please make it extendable, use a more generic name for one (and only
> one) environment variable. It makes littel sense to pollyte the
> envrionment with N additional variables. For example, call it
> "hwconfig". Allow that this variable holds a list of config settings,
> separated for example by comma or colon or ...

agreed - assuming this truly is indetectable by s/w.  Does "setenv
dip_sw_1_4 on" work more universally?

Kim

[U-Boot] [PATCH 3/6] fsl_dr_usb: Fixup disabled USB controllers nodes in device tree

[Anton Vorontsov]

We should add status = "disabled" property when USB controller can't
be used (for example when USB pins muxed away to another device).

Also convert whole fdt_fixup_dr_usb() to use more compact routines
from fdt_support.h.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/usb/fsl_dr_usb.c |   44 +++++++++++++++++---------------------------
 1 files changed, 17 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/fsl_dr_usb.c b/drivers/usb/fsl_dr_usb.c
index af9797f..a646846 100644
--- a/drivers/usb/fsl_dr_usb.c
+++ b/drivers/usb/fsl_dr_usb.c
@@ -10,43 +10,33 @@
  */
 
 #include <common.h>
-#include <libfdt.h>
+#include <fsl_can_use.h>
+#include <fdt_support.h>
 
 void fdt_fixup_dr_usb(void *blob, bd_t *bd)
 {
+	const char *compat = "fsl-usb2-dr";
 	char *mode;
 	char *type;
-	const char *compat = "fsl-usb2-dr";
-	const char *prop_mode = "dr_mode";
-	const char *prop_type = "phy_type";
-	int node_offset;
-	int err;
+
+	if (!fsl_can_use_dr_usb()) {
+		const char *reason = "disabled";
+
+		do_fixup_by_compat(blob, compat, "status", reason,
+				   strlen(reason) + 1, 1);
+		return;
+	}
 
 	mode = getenv("usb_dr_mode");
 	type = getenv("usb_phy_type");
 	if (!mode && !type)
 		return;
 
-	node_offset = fdt_node_offset_by_compatible(blob, 0, compat);
-	if (node_offset < 0) {
-		printf("WARNING: could not find compatible node %s: %s.\n",
-			compat, fdt_strerror(node_offset));
-		return;
-	}
+	if (mode)
+		do_fixup_by_compat(blob, compat, "dr_mode", mode,
+				   strlen(mode) + 1, 1);
 
-	if (mode) {
-		err = fdt_setprop(blob, node_offset, prop_mode, mode,
-				  strlen(mode) + 1);
-		if (err < 0)
-			printf("WARNING: could not set %s for %s: %s.\n",
-			       prop_mode, compat, fdt_strerror(err));
-	}
-
-	if (type) {
-		err = fdt_setprop(blob, node_offset, prop_type, type,
-				  strlen(type) + 1);
-		if (err < 0)
-			printf("WARNING: could not set %s for %s: %s.\n",
-			       prop_type, compat, fdt_strerror(err));
-	}
+	if (type)
+		do_fixup_by_compat(blob, compat, "type", type,
+				   strlen(type) + 1, 1);
 }
-- 
1.5.6.5

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

This patch implements fdt_fixup_esdhc() function that is used to fixup
the device tree.

The function adds status = "disabled" propery if esdhc pins muxed away,
otherwise it fixups clock-frequency for esdhc nodes.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/mmc/fsl_esdhc.c |   22 ++++++++++++++++++++++
 include/fsl_esdhc.h     |    8 ++++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0ba45cd..fe8bd86 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -33,6 +33,8 @@
 #include <malloc.h>
 #include <mmc.h>
 #include <fsl_esdhc.h>
+#include <fsl_can_use.h>
+#include <fdt_support.h>
 #include <asm/io.h>
 
 
@@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
 {
 	return esdhc_initialize(bis);
 }
+
+#ifdef CONFIG_MPC85xx
+#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
+#else
+#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
+#endif
+
+void fdt_fixup_esdhc(void *blob, bd_t *bd)
+{
+	if (!fsl_can_use_esdhc()) {
+		const char *reason = "disabled";
+
+		do_fixup_by_compat(blob, ESDHC_COMPATIBLE, "status", reason,
+				   strlen(reason) + 1, 1);
+		return;
+	}
+
+	do_fixup_by_compat_u32(blob, ESDHC_COMPATIBLE, "clock-frequency",
+			       gd->sdhc_clk, 1);
+}
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index 0a5c5d6..89b8304 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -26,6 +26,8 @@
 #ifndef  __FSL_ESDHC_H__
 #define	__FSL_ESDHC_H__
 
+#include <asm/errno.h>
+
 /* FSL eSDHC-specific constants */
 #define SYSCTL			0x0002e02c
 #define SYSCTL_INITA		0x08000000
@@ -140,6 +142,12 @@
 #define ESDHC_HOSTCAPBLT_DMAS	0x00400000
 #define ESDHC_HOSTCAPBLT_HSS	0x00200000
 
+#ifdef CONFIG_FSL_ESDHC
 int fsl_esdhc_mmc_init(bd_t *bis);
+void fdt_fixup_esdhc(void *blob, bd_t *bd);
+#else
+static inline int fsl_esdhc_mmc_init(bd_t *bis) { return -ENOSYS; }
+static inline void fdt_fixup_esdhc(void *blob, bd_t *bd) {}
+#endif /* CONFIG_FSL_ESDHC */
 
 #endif  /* __FSL_ESDHC_H__ */
-- 
1.5.6.5

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Andy Fleming]

On Thu, Feb 19, 2009 at 9:45 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> This patch implements fdt_fixup_esdhc() function that is used to fixup
> the device tree.
>
> The function adds status = "disabled" propery if esdhc pins muxed away,
> otherwise it fixups clock-frequency for esdhc nodes.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> ?drivers/mmc/fsl_esdhc.c | ? 22 ++++++++++++++++++++++
> ?include/fsl_esdhc.h ? ? | ? ?8 ++++++++
> ?2 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 0ba45cd..fe8bd86 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -33,6 +33,8 @@
> ?#include <malloc.h>
> ?#include <mmc.h>
> ?#include <fsl_esdhc.h>
> +#include <fsl_can_use.h>
> +#include <fdt_support.h>
> ?#include <asm/io.h>
>
>
> @@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
> ?{
> ? ? ? ?return esdhc_initialize(bis);
> ?}
> +
> +#ifdef CONFIG_MPC85xx
> +#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
> +#else
> +#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
> +#endif

Isn't there a more global means of doing this?  I don't like having
the 8536/8379 in the driver, itself.  Actually, there is.  Move these
to the config file.  But there should be a compatible property that
works for all esdhc devices.

Andy

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

Hi Andy,

Sorry for the late response,

On Fri, Mar 06, 2009 at 07:25:55PM -0600, Andy Fleming wrote:
> On Thu, Feb 19, 2009 at 9:45 AM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> > This patch implements fdt_fixup_esdhc() function that is used to fixup
> > the device tree.
> >
> > The function adds status = "disabled" propery if esdhc pins muxed away,
> > otherwise it fixups clock-frequency for esdhc nodes.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > ?drivers/mmc/fsl_esdhc.c | ? 22 ++++++++++++++++++++++
> > ?include/fsl_esdhc.h ? ? | ? ?8 ++++++++
> > ?2 files changed, 30 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> > index 0ba45cd..fe8bd86 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -33,6 +33,8 @@
> > ?#include <malloc.h>
> > ?#include <mmc.h>
> > ?#include <fsl_esdhc.h>
> > +#include <fsl_can_use.h>
> > +#include <fdt_support.h>
> > ?#include <asm/io.h>
> >
> >
> > @@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
> > ?{
> > ? ? ? ?return esdhc_initialize(bis);
> > ?}
> > +
> > +#ifdef CONFIG_MPC85xx
> > +#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
> > +#else
> > +#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
> > +#endif
> 
> Isn't there a more global means of doing this?  I don't like having
> the 8536/8379 in the driver, itself.

But that's how we prefer bindings nowadays.

> Actually, there is.  Move these
> to the config file.  But there should be a compatible property that
> works for all esdhc devices.

Starting from MPC83xx/MPC85xx GPIO controllers, we try to
differentiate 85xx and 83xx parts. I.e. 85xx family doesn't
specify 83xx family's compatible entries, even if the controllers
are compatible. I'm just following the trend.

So the current scheme is:
"fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;

See this discussion:

http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html

And some quotes from accepted bindings:

 Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt:
  - compatible : "fsl,<CHIP>-gpio" followed by "fsl,mpc8349-gpio" for
    83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.

 Documentation/powerpc/dts-bindings/fsl/esdhc.txt:
  - compatible : should be
    "fsl,<chip>-esdhc", "fsl,mpc8379-esdhc" for MPC83xx processors.
    "fsl,<chip>-esdhc", "fsl,mpc8536-esdhc" for MPC85xx processors.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Scott Wood]

On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > Isn't there a more global means of doing this?  I don't like having
> > the 8536/8379 in the driver, itself.
> 
> But that's how we prefer bindings nowadays.

Block version numbers are better, if available.

> > Actually, there is.  Move these to the config file.  But there should
> > be a compatible property that works for all esdhc devices.
> 
> Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> 85xx and 83xx parts.  I.e. 85xx family doesn't specify 83xx family's
> compatible entries, even if the controllers are compatible. I'm just
> following the trend.

I must have missed that memo...

Why would we not recognize the compatibility if it exists?

> So the current scheme is:
> "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> 
> See this discussion:
> 
> http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html

Bah.  I don't see how it's any more "confusing to show 8610 and 8349 in
the same dev tree" than in is to show, say, 8313 and 8349 in the same
device tree.  The concept of component A being compatible with component
B doesn't somehow get mysterious when the systems involved have a
different type of core.

-Scott

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > Isn't there a more global means of doing this?  I don't like having
> > > the 8536/8379 in the driver, itself.
> > 
> > But that's how we prefer bindings nowadays.
> 
> Block version numbers are better, if available.
> 
> > > Actually, there is.  Move these to the config file.  But there should
> > > be a compatible property that works for all esdhc devices.
> > 
> > Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> > 85xx and 83xx parts.  I.e. 85xx family doesn't specify 83xx family's
> > compatible entries, even if the controllers are compatible. I'm just
> > following the trend.
> 
> I must have missed that memo...
> 
> Why would we not recognize the compatibility if it exists?
> 
> > So the current scheme is:
> > "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> > 
> > See this discussion:
> > 
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
> 
> Bah.  I don't see how it's any more "confusing to show 8610 and 8349 in
> the same dev tree" than in is to show, say, 8313 and 8349 in the same
> device tree.  The concept of component A being compatible with component
> B doesn't somehow get mysterious when the systems involved have a
> different type of core.

I feel a bit dizzy.

For a year I thought that we should specify first compatible chip
in the last compatible entry, then I've been told that the first
compatible chip _in a family_ should be specified and we used
this during, say, another six months. And now you're saying that a
block version number is preferred.

Now all possible compatible naming schemes are used in various
device trees for various devices.

Can we have a guideline set in a stone that we all agree with?

In general, I follow maintainer's opinion, so I'm waiting for
Kumar's decision on that matter, and depending on the results
I'll modify the bindings and/or patches.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Kim Phillips]

On Thu, 30 Apr 2009 22:59:59 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > > Isn't there a more global means of doing this?  I don't like having
> > > > the 8536/8379 in the driver, itself.
> > > 
> > > But that's how we prefer bindings nowadays.
> > 
> > Block version numbers are better, if available.
> > 
> > > > Actually, there is.  Move these to the config file.  But there should
> > > > be a compatible property that works for all esdhc devices.
> > > 
> > > Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> > > 85xx and 83xx parts.  I.e. 85xx family doesn't specify 83xx family's
> > > compatible entries, even if the controllers are compatible. I'm just
> > > following the trend.
> > 
> > I must have missed that memo...
> > 
> > Why would we not recognize the compatibility if it exists?
> > 
> > > So the current scheme is:
> > > "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> > > 
> > > See this discussion:
> > > 
> > > http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
> > 
> > Bah.  I don't see how it's any more "confusing to show 8610 and 8349 in
> > the same dev tree" than in is to show, say, 8313 and 8349 in the same
> > device tree.  The concept of component A being compatible with component
> > B doesn't somehow get mysterious when the systems involved have a
> > different type of core.
> 
> I feel a bit dizzy.
> 
> For a year I thought that we should specify first compatible chip
> in the last compatible entry, then I've been told that the first
> compatible chip _in a family_ should be specified and we used
> this during, say, another six months. And now you're saying that a
> block version number is preferred.
> 
> Now all possible compatible naming schemes are used in various
> device trees for various devices.
> 
> Can we have a guideline set in a stone that we all agree with?
> 
> In general, I follow maintainer's opinion, so I'm waiting for
> Kumar's decision on that matter, and depending on the results
> I'll modify the bindings and/or patches.

I, for one, have disagreed with the superfluous <CHIP> prefix for quite
some time now - see the SEC node description and/or
http://ozlabs.org/pipermail/linuxppc-dev/2008-July/058867.html.

fyi block version number is available for the eSDHC block.  It's
version is at v0.9 for the 8379, 1.0 for the mpc8536rev1, and 1.0.1 for
the mpc8536rev1.1.  I'm not familiar with it enough to know whether the
3rd degree of precision is needed though.

Kim

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> On Thu, 30 Apr 2009 22:59:59 +0400
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > > On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > > > Isn't there a more global means of doing this?  I don't like having
> > > > > the 8536/8379 in the driver, itself.
> > > > 
> > > > But that's how we prefer bindings nowadays.
> > > 
> > > Block version numbers are better, if available.
> > > 
> > > > > Actually, there is.  Move these to the config file.  But there should
> > > > > be a compatible property that works for all esdhc devices.
> > > > 
> > > > Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> > > > 85xx and 83xx parts.  I.e. 85xx family doesn't specify 83xx family's
> > > > compatible entries, even if the controllers are compatible. I'm just
> > > > following the trend.
> > > 
> > > I must have missed that memo...
> > > 
> > > Why would we not recognize the compatibility if it exists?
> > > 
> > > > So the current scheme is:
> > > > "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> > > > 
> > > > See this discussion:
> > > > 
> > > > http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
> > > 
> > > Bah.  I don't see how it's any more "confusing to show 8610 and 8349 in
> > > the same dev tree" than in is to show, say, 8313 and 8349 in the same
> > > device tree.  The concept of component A being compatible with component
> > > B doesn't somehow get mysterious when the systems involved have a
> > > different type of core.
> > 
> > I feel a bit dizzy.
> > 
> > For a year I thought that we should specify first compatible chip
> > in the last compatible entry, then I've been told that the first
> > compatible chip _in a family_ should be specified and we used
> > this during, say, another six months. And now you're saying that a
> > block version number is preferred.
> > 
> > Now all possible compatible naming schemes are used in various
> > device trees for various devices.
> > 
> > Can we have a guideline set in a stone that we all agree with?
> > 
> > In general, I follow maintainer's opinion, so I'm waiting for
> > Kumar's decision on that matter, and depending on the results
> > I'll modify the bindings and/or patches.
> 
> I, for one, have disagreed with the superfluous <CHIP> prefix for quite
> some time now - see the SEC node description and/or
> http://ozlabs.org/pipermail/linuxppc-dev/2008-July/058867.html.
> 
> fyi block version number is available for the eSDHC block.  It's
> version is at v0.9 for the 8379, 1.0 for the mpc8536rev1, and 1.0.1 for
> the mpc8536rev1.1.  I'm not familiar with it enough to know whether the
> 3rd degree of precision is needed though.

What if there is some errata in 8377 chip (with 1.0 revision), and
not in 8378 chip (also 1.0 revision)?

IMO <chip> prefix is more specific than a block revision.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

On Thu, Apr 30, 2009 at 11:35:34PM +0400, Anton Vorontsov wrote:
> On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> > On Thu, 30 Apr 2009 22:59:59 +0400
> > Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > 
> > > On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > > > On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > > > > Isn't there a more global means of doing this?  I don't like having
> > > > > > the 8536/8379 in the driver, itself.
> > > > > 
> > > > > But that's how we prefer bindings nowadays.
> > > > 
> > > > Block version numbers are better, if available.
> > > > 
> > > > > > Actually, there is.  Move these to the config file.  But there should
> > > > > > be a compatible property that works for all esdhc devices.
> > > > > 
> > > > > Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> > > > > 85xx and 83xx parts.  I.e. 85xx family doesn't specify 83xx family's
> > > > > compatible entries, even if the controllers are compatible. I'm just
> > > > > following the trend.
> > > > 
> > > > I must have missed that memo...
> > > > 
> > > > Why would we not recognize the compatibility if it exists?
> > > > 
> > > > > So the current scheme is:
> > > > > "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> > > > > 
> > > > > See this discussion:
> > > > > 
> > > > > http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
> > > > 
> > > > Bah.  I don't see how it's any more "confusing to show 8610 and 8349 in
> > > > the same dev tree" than in is to show, say, 8313 and 8349 in the same
> > > > device tree.  The concept of component A being compatible with component
> > > > B doesn't somehow get mysterious when the systems involved have a
> > > > different type of core.
> > > 
> > > I feel a bit dizzy.
> > > 
> > > For a year I thought that we should specify first compatible chip
> > > in the last compatible entry, then I've been told that the first
> > > compatible chip _in a family_ should be specified and we used
> > > this during, say, another six months. And now you're saying that a
> > > block version number is preferred.
> > > 
> > > Now all possible compatible naming schemes are used in various
> > > device trees for various devices.
> > > 
> > > Can we have a guideline set in a stone that we all agree with?
> > > 
> > > In general, I follow maintainer's opinion, so I'm waiting for
> > > Kumar's decision on that matter, and depending on the results
> > > I'll modify the bindings and/or patches.
> > 
> > I, for one, have disagreed with the superfluous <CHIP> prefix for quite
> > some time now - see the SEC node description and/or
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-July/058867.html.
> > 
> > fyi block version number is available for the eSDHC block.  It's
> > version is at v0.9 for the 8379, 1.0 for the mpc8536rev1, and 1.0.1 for
> > the mpc8536rev1.1.  I'm not familiar with it enough to know whether the
> > 3rd degree of precision is needed though.
> 
> What if there is some errata in 8377 chip (with 1.0 revision), and
> not in 8378 chip (also 1.0 revision)?

Oh, and btw, reference manual for 8379 specify that it has eSDHC
version 1.0. Is v0.9 some internal FSL numbering scheme? Then
it's also not a good idea to use it in the public device tree.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Kim Phillips]

On Thu, 30 Apr 2009 23:39:11 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> On Thu, Apr 30, 2009 at 11:35:34PM +0400, Anton Vorontsov wrote:
> > On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> > > On Thu, 30 Apr 2009 22:59:59 +0400
> > > Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > 
> > > > On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > > > > On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > > > > > Isn't there a more global means of doing this?  I don't like having
> > > > > > > the 8536/8379 in the driver, itself.
> > > > > > 
> > > > > > But that's how we prefer bindings nowadays.
> > > > > 
> > > > > Block version numbers are better, if available.
> > > > > 
> > > > > > > Actually, there is.  Move these to the config file.  But there should
> > > > > > > be a compatible property that works for all esdhc devices.
> > > > > > 
> > > > > > Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> > > > > > 85xx and 83xx parts.  I.e. 85xx family doesn't specify 83xx family's
> > > > > > compatible entries, even if the controllers are compatible. I'm just
> > > > > > following the trend.
> > > > > 
> > > > > I must have missed that memo...
> > > > > 
> > > > > Why would we not recognize the compatibility if it exists?
> > > > > 
> > > > > > So the current scheme is:
> > > > > > "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> > > > > > 
> > > > > > See this discussion:
> > > > > > 
> > > > > > http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
> > > > > 
> > > > > Bah.  I don't see how it's any more "confusing to show 8610 and 8349 in
> > > > > the same dev tree" than in is to show, say, 8313 and 8349 in the same
> > > > > device tree.  The concept of component A being compatible with component
> > > > > B doesn't somehow get mysterious when the systems involved have a
> > > > > different type of core.
> > > > 
> > > > I feel a bit dizzy.
> > > > 
> > > > For a year I thought that we should specify first compatible chip
> > > > in the last compatible entry, then I've been told that the first
> > > > compatible chip _in a family_ should be specified and we used
> > > > this during, say, another six months. And now you're saying that a
> > > > block version number is preferred.
> > > > 
> > > > Now all possible compatible naming schemes are used in various
> > > > device trees for various devices.
> > > > 
> > > > Can we have a guideline set in a stone that we all agree with?
> > > > 
> > > > In general, I follow maintainer's opinion, so I'm waiting for
> > > > Kumar's decision on that matter, and depending on the results
> > > > I'll modify the bindings and/or patches.
> > > 
> > > I, for one, have disagreed with the superfluous <CHIP> prefix for quite
> > > some time now - see the SEC node description and/or
> > > http://ozlabs.org/pipermail/linuxppc-dev/2008-July/058867.html.
> > > 
> > > fyi block version number is available for the eSDHC block.  It's
> > > version is at v0.9 for the 8379, 1.0 for the mpc8536rev1, and 1.0.1 for
> > > the mpc8536rev1.1.  I'm not familiar with it enough to know whether the
> > > 3rd degree of precision is needed though.
> > 
> > What if there is some errata in 8377 chip (with 1.0 revision), and
> > not in 8378 chip (also 1.0 revision)?
> 
> Oh, and btw, reference manual for 8379 specify that it has eSDHC
> version 1.0. Is v0.9 some internal FSL numbering scheme? Then
> it's also not a good idea to use it in the public device tree.

sure, I may be wrong/out of date here.  But since the data is publicly
available, this is even more reason for me to want to use it.

Kim

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Kim Phillips]

On Thu, 30 Apr 2009 23:35:34 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> What if there is some errata in 8377 chip (with 1.0 revision), and
> not in 8378 chip (also 1.0 revision)?

I believe they are in fact the same chip, just with different fuses
blown.

> IMO <chip> prefix is more specific than a block revision.

It's a waste IMO.  H/w designers do just like us; they copy-n-paste IP
blocks into chips.

Kim

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

On Thu, Apr 30, 2009 at 02:59:37PM -0500, Kim Phillips wrote:
> On Thu, 30 Apr 2009 23:35:34 +0400
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > What if there is some errata in 8377 chip (with 1.0 revision), and
> > not in 8378 chip (also 1.0 revision)?
> 
> I believe they are in fact the same chip, just with different fuses
> blown.

Sure, that was just a what-if, an imaginary example.

> > IMO <chip> prefix is more specific than a block revision.
> 
> It's a waste IMO.  H/w designers do just like us; they copy-n-paste IP
> blocks into chips.

Sometimes errors happen even during copy-paste procedure. Or
for example HW designers have made some minor (they thought) change,
and didn't bother to bump the revision. Later we observe that the
change is the cause of some errata, but we can't deal with it
because device-tree isn't specific enough.

Of course this is just my imagination, but theoretically possible?

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Scott Wood]

On Fri, May 01, 2009 at 12:20:51AM +0400, Anton Vorontsov wrote:
> Sometimes errors happen even during copy-paste procedure. Or
> for example HW designers have made some minor (they thought) change,
> and didn't bother to bump the revision. Later we observe that the
> change is the cause of some errata, but we can't deal with it
> because device-tree isn't specific enough.
> 
> Of course this is just my imagination, but theoretically possible?

It's possible -- but not likely enough to warrant using the chip name if
a usable block number is available (it's more likely that a future rev of
the same chip number will have a different logic block version).  PVR or
information elsewhere in the device tree could be used in such cases.

Note that it can even happen at board level.  Accessing power management
controller registers (which are SoC-internal) on early revs of the
8313erdb would lock the board (unless JTAG is plugged in or a resistor
modification is made), at no fault of the 8313e chip itself.  But we
don't put the board name in all of the compatibles...

-Scott

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Scott Wood]

On Fri, May 01, 2009 at 10:59:13AM -0500, Scott Wood wrote:
> It's possible -- but not likely enough to warrant using the chip name if
> a usable block number is available (it's more likely that a future rev of
> the same chip number will have a different logic block version).  PVR or
> information elsewhere in the device tree could be used in such cases.

I meant SVR, not PVR, of course.

-Scott

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Andy Fleming]

On Apr 29, 2009, at 4:20 PM, Anton Vorontsov wrote:

> Hi Andy,
>
> Sorry for the late response,
>
> On Fri, Mar 06, 2009 at 07:25:55PM -0600, Andy Fleming wrote:
>>>
>>>
>>>
>>> @@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
>>> ? {
>>> ?  ?  ?  ? return esdhc_initialize(bis);
>>> ? }
>>> +
>>> +#ifdef CONFIG_MPC85xx
>>> +#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
>>> +#else
>>> +#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
>>> +#endif
>>
>> Isn't there a more global means of doing this?  I don't like having
>> the 8536/8379 in the driver, itself.
>
> But that's how we prefer bindings nowadays.
>
>> Actually, there is.  Move these
>> to the config file.  But there should be a compatible property that
>> works for all esdhc devices.
>
> Starting from MPC83xx/MPC85xx GPIO controllers, we try to
> differentiate 85xx and 83xx parts. I.e. 85xx family doesn't
> specify 83xx family's compatible entries, even if the controllers
> are compatible. I'm just following the trend.

I'm not strongly interested in arguing about what the compatible  
should be.  Don't specify it here.  Put it in the config file.

[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

On Fri, May 01, 2009 at 07:32:12PM -0500, Andy Fleming wrote:
>
> On Apr 29, 2009, at 4:20 PM, Anton Vorontsov wrote:
>
>> Hi Andy,
>>
>> Sorry for the late response,
>>
>> On Fri, Mar 06, 2009 at 07:25:55PM -0600, Andy Fleming wrote:
>>>>
>>>>
>>>>
>>>> @@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
>>>> ? {
>>>> ?  ?  ?  ? return esdhc_initialize(bis);
>>>> ? }
>>>> +
>>>> +#ifdef CONFIG_MPC85xx
>>>> +#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
>>>> +#else
>>>> +#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
>>>> +#endif
>>>
>>> Isn't there a more global means of doing this?  I don't like having
>>> the 8536/8379 in the driver, itself.
>>
>> But that's how we prefer bindings nowadays.
>>
>>> Actually, there is.  Move these
>>> to the config file.  But there should be a compatible property that
>>> works for all esdhc devices.
>>
>> Starting from MPC83xx/MPC85xx GPIO controllers, we try to
>> differentiate 85xx and 83xx parts. I.e. 85xx family doesn't
>> specify 83xx family's compatible entries, even if the controllers
>> are compatible. I'm just following the trend.
>
> I'm not strongly interested in arguing about what the compatible should 
> be.  Don't specify it here.  Put it in the config file.

Will do, thanks.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 5/6] mpc83xx: MPC837XERDB: Add support for FSL eSDHC

[Anton Vorontsov]

This patch adds support for eSDHC on MPC837XERDB boards. The WP
switch doesn't seem to work on RDB boards though, the WP pin is
always asserted (can see the pin state when it's in GPIO mode).

FSL DR USB and FSL eSDHC are mutually exclusive because of pins
multiplexing, so user should specify `usb_or_esdhc' environment
variable to choose between the devices.

p.s.
Now we're very close to a monitor len limit (196 bytes left using
gcc-4.2.0), so also increase the monitor len by one sector (64 KB).

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 board/freescale/mpc837xerdb/mpc837xerdb.c |   18 ++++++++++++++++++
 include/configs/MPC837XERDB.h             |   17 ++++++++++++++++-
 2 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/board/freescale/mpc837xerdb/mpc837xerdb.c b/board/freescale/mpc837xerdb/mpc837xerdb.c
index 8cbac14..0fc3ec6 100644
--- a/board/freescale/mpc837xerdb/mpc837xerdb.c
+++ b/board/freescale/mpc837xerdb/mpc837xerdb.c
@@ -20,6 +20,8 @@
 #include <spd_sdram.h>
 #include <vsc7385.h>
 #include <fsl_dr_usb.h>
+#include <fsl_esdhc.h>
+#include <fsl_can_use.h>
 
 #if defined(CONFIG_SYS_DRAM_TEST)
 int
@@ -167,6 +169,21 @@ int board_early_init_f(void)
 	return 0;
 }
 
+#ifdef CONFIG_FSL_ESDHC
+int board_mmc_init(bd_t *bd)
+{
+	struct immap __iomem *im = (struct immap __iomem *)CONFIG_SYS_IMMR;
+
+	if (!fsl_can_use_esdhc())
+		return 0;
+
+	clrsetbits_be32(&im->sysconf.sicrl, SICRL_USB_B, SICRL_USB_B_SD);
+	clrsetbits_be32(&im->sysconf.sicrh, SICRH_SPI, SICRH_SPI_SD);
+
+	return fsl_esdhc_mmc_init(bd);
+}
+#endif
+
 /*
  * Miscellaneous late-boot configurations
  *
@@ -196,5 +213,6 @@ void ft_board_setup(void *blob, bd_t *bd)
 #endif
 	ft_cpu_setup(blob, bd);
 	fdt_fixup_dr_usb(blob, bd);
+	fdt_fixup_esdhc(blob, bd);
 }
 #endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/include/configs/MPC837XERDB.h b/include/configs/MPC837XERDB.h
index df7e746..a0f4fb2 100644
--- a/include/configs/MPC837XERDB.h
+++ b/include/configs/MPC837XERDB.h
@@ -228,7 +228,7 @@
 #undef	CONFIG_SYS_RAMBOOT
 #endif
 
-#define CONFIG_SYS_MONITOR_LEN		(256 * 1024) /* Reserve 256 kB for Mon */
+#define CONFIG_SYS_MONITOR_LEN		(320 * 1024) /* Reserve 320 kB for Mon */
 #define CONFIG_SYS_MALLOC_LEN		(512 * 1024) /* Reserved for malloc */
 
 /*
@@ -342,6 +342,9 @@
 #define CONFIG_OF_BOARD_SETUP	1
 #define CONFIG_OF_STDOUT_VIA_ALIAS 1
 
+#define CONFIG_SYS_64BIT_STRTOUL		1
+#define CONFIG_SYS_64BIT_VSPRINTF		1
+
 /* I2C */
 #define CONFIG_HARD_I2C		/* I2C with hardware support */
 #undef	CONFIG_SOFT_I2C		/* I2C bit-banged */
@@ -510,6 +513,18 @@
 
 #undef CONFIG_WATCHDOG		/* watchdog disabled */
 
+#define CONFIG_MMC     1
+
+#ifdef CONFIG_MMC
+#define CONFIG_FSL_ESDHC
+#define CONFIG_SYS_FSL_ESDHC_ADDR	CONFIG_SYS_MPC83xx_ESDHC_ADDR
+#define CONFIG_CMD_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+#define CONFIG_DOS_PARTITION
+#endif
+
 /*
  * Miscellaneous configurable options
  */
-- 
1.5.6.5

[U-Boot] [PATCH 6/6] mpc83xx: MPC837XEMDS: Fixup eSDHC nodes in device tree

[Anton Vorontsov]

fdt_fixup_esdhc() will either disable or enable eSDHC nodes,
and also will fixup clock-frequency property.

Plus, since DR USB and eSDHC are mutually exclusive, only configure
eSDHC if usb_or_esdhc environment variable is set to 'esdhc'.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 board/freescale/mpc837xemds/mpc837xemds.c |   37 ++++++++++++++++++----------
 1 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/board/freescale/mpc837xemds/mpc837xemds.c b/board/freescale/mpc837xemds/mpc837xemds.c
index 376b7f2..1084162 100644
--- a/board/freescale/mpc837xemds/mpc837xemds.c
+++ b/board/freescale/mpc837xemds/mpc837xemds.c
@@ -19,12 +19,13 @@
 #include <libfdt.h>
 #include <fdt_support.h>
 #include <fsl_dr_usb.h>
+#include <fsl_esdhc.h>
+#include <fsl_can_use.h>
 #include "pci.h"
 #include "../common/pq-mds-pib.h"
 
 int board_early_init_f(void)
 {
-	struct immap __iomem *im = (struct immap __iomem *)CONFIG_SYS_IMMR;
 	u8 *bcsr = (u8 *)CONFIG_SYS_BCSR;
 
 	/* Enable flash write */
@@ -32,18 +33,6 @@ int board_early_init_f(void)
 	/* Clear all of the interrupt of BCSR */
 	bcsr[0xe] = 0xff;
 
-#ifdef CONFIG_MMC
-	/* Set SPI_SD, SER_SD, and IRQ4_WP so that SD signals go through */
-	bcsr[0xc] |= 0x4c;
-
-	/* Set proper bits in SICR to allow SD signals through */
-	clrsetbits_be32(&im->sysconf.sicrl, SICRL_USB_B, SICRL_USB_B_SD);
-
-	clrsetbits_be32(&im->sysconf.sicrh, (SICRH_GPIO2_E | SICRH_SPI),
-			(SICRH_GPIO2_E_SD | SICRH_SPI_SD));
-
-#endif
-
 #ifdef CONFIG_FSL_SERDES
 	immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
 	u32 spridr = in_be32(&immr->sysconf.spridr);
@@ -73,6 +62,27 @@ int board_early_init_f(void)
 	return 0;
 }
 
+#ifdef CONFIG_FSL_ESDHC
+int board_mmc_init(bd_t *bd)
+{
+	struct immap __iomem *im = (struct immap __iomem *)CONFIG_SYS_IMMR;
+	u8 *bcsr = (u8 *)CONFIG_SYS_BCSR;
+
+	if (!fsl_can_use_esdhc())
+		return 0;
+
+	/* Set SPI_SD, SER_SD, and IRQ4_WP so that SD signals go through */
+	bcsr[0xc] |= 0x4c;
+
+	/* Set proper bits in SICR to allow SD signals through */
+	clrsetbits_be32(&im->sysconf.sicrl, SICRL_USB_B, SICRL_USB_B_SD);
+	clrsetbits_be32(&im->sysconf.sicrh, SICRH_GPIO2_E | SICRH_SPI,
+			SICRH_GPIO2_E_SD | SICRH_SPI_SD);
+
+	return fsl_esdhc_mmc_init(bd);
+}
+#endif
+
 #if defined(CONFIG_TSEC1) || defined(CONFIG_TSEC2)
 int board_eth_init(bd_t *bd)
 {
@@ -323,6 +333,7 @@ void ft_board_setup(void *blob, bd_t *bd)
 	ft_cpu_setup(blob, bd);
 	ft_tsec_fixup(blob, bd);
 	fdt_fixup_dr_usb(blob, bd);
+	fdt_fixup_esdhc(blob, bd);
 #ifdef CONFIG_PCI
 	ft_pci_setup(blob, bd);
 	if (board_pci_host_broken())
-- 
1.5.6.5