[U-Boot] [PATCH 0/6] eSDHC/DR USB switching on MPC837X boards
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...
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 */
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
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 */
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:
- USB ULPI PHY vs. TSEC1 on MPC8315E-RDB boards;
- 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
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:
- USB ULPI PHY vs. TSEC1 on MPC8315E-RDB boards;
- 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
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); }
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__ */
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
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,
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
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.
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
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.
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.
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
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
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,
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
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
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.
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.
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 */
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())
participants (7)
-
Andy Fleming -
Andy Fleming -
Anton Vorontsov -
Jerry Van Baren -
Kim Phillips -
Scott Wood -
Wolfgang Denk