Skip to contentSkip to conversation

ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet

PATCH In review Vitaly Bordug 5 participants 8 messages Nov 28, 2005 – Dec 8, 2005

lore
Share & tools
lore

Vitaly Bordug

author
#0 lore raw

PATCH 1/1 ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet

Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, 866ADS and 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.

Signed-off-by Vitaly Bordug <[email protected]>

---
Sincerely,
Vitaly

arch/ppc/Kconfig +47 -0
index 8fa51b0..8e6fcb2 100644
@@ -506,6 +506,53 @@ config WINCEPT
 
 endchoice
 
+menu "Freescale Ethernet driver platform-specific options"
+	depends on FS_ENET
+
+	config MPC8xx_SECOND_ETH
+	bool "Second Ethernet channel"
+	depends on (MPC885ADS || MPC86XADS)
+	default y
+	help
+	  This enables support for second Ethernet on MPC885ADS and MPC86xADS boards.
+	  The latter will use SCC1, for 885ADS you can select it below.
+
+	choice
+		prompt "Second Ethernet channel"
+		depends on MPC8xx_SECOND_ETH
+		default MPC8xx_SECOND_ETH_FEC2
+
+		config MPC8xx_SECOND_ETH_FEC2
+		bool "FEC2"
+		depends on MPC885ADS
+		help
+		  Enable FEC2 to serve as 2-nd Ethernet channel. Note that SMC2
+		  (often 2-nd UART) will not work if this is enabled.
+
+		config MPC8xx_SECOND_ETH_SCC1
+		bool "SCC1"
+		depends on MPC86XADS
+		select MPC8xx_SCC_ENET_FIXED
+		help
+		  Enable SCC1 to serve as 2-nd Ethernet channel. Note that SMC1
+		  (often 1-nd UART) will not work if this is enabled.
+
+		config MPC8xx_SECOND_ETH_SCC3
+		bool "SCC3"
+		depends on MPC885ADS
+		help
+		  Enable SCC3 to serve as 2-nd Ethernet channel. Note that SMC1
+		  (often 1-nd UART) will not work if this is enabled.
+
+	endchoice
+
+	config MPC8xx_SCC_ENET_FIXED
+	depends on MPC8xx_SECOND_ETH_SCC
+	default n
+	bool "Use fixed MII-less mode for SCC Ethernet"
+
+endmenu
+
 choice
 	prompt "Machine Type"
 	depends on 6xx || POWER3 || POWER4
arch/ppc/platforms/Makefile +4 -0
index 7c5cdab..ee50b0d 100644
@@ -22,6 +22,8 @@ ifeq ($(CONFIG_PPC_PMAC),y)
 obj-$(CONFIG_NVRAM)		+= pmac_nvram.o
 obj-$(CONFIG_CPU_FREQ_PMAC)	+= pmac_cpufreq.o
 endif
+
+obj-$(CONFIG_ADS8272)		+= mpc8272ads_setup.o
 obj-$(CONFIG_PMAC_BACKLIGHT)	+= pmac_backlight.o
 obj-$(CONFIG_PREP_RESIDUAL)	+= residual.o
 obj-$(CONFIG_PQ2ADS)		+= pq2ads.o

@@ -45,6 +47,8 @@ obj-$(CONFIG_SBC82xx)		+= sbc82xx.o
 obj-$(CONFIG_SPRUCE)		+= spruce.o
 obj-$(CONFIG_LITE5200)		+= lite5200.o
 obj-$(CONFIG_EV64360)		+= ev64360.o
+obj-$(CONFIG_MPC86XADS)		+= mpc866ads_setup.o
+obj-$(CONFIG_MPC885ADS)		+= mpc885ads_setup.o
 
 ifeq ($(CONFIG_SMP),y)
 obj-$(CONFIG_PPC_PMAC)		+= pmac_smp.o
arch/ppc/platforms/fads.h +1 -1
index a48fb8d..e1c0b1b 100644
@@ -112,7 +112,7 @@
 
 /* CPM Ethernet through SCC1 or SCC2 */
 
-#ifdef CONFIG_SCC1_ENET		/* Probably 860 variant */
+#if defined(CONFIG_SCC1_ENET) || defined(CONFIG_MPC8xx_SECOND_ETH_SCC1)		/* Probably 860 variant */
 /* Bits in parallel I/O port registers that have to be set/cleared
  * to configure the pins for SCC1 use.
  * TCLK - CLK1, RCLK - CLK2.
arch/ppc/platforms/mpc8272ads_setup.c new file +253 -0

253 lines not on this page · raw message

arch/ppc/platforms/mpc866ads_setup.c new file +283 -0

283 lines not on this page · raw message

arch/ppc/platforms/mpc885ads_setup.c new file +400 -0

400 lines not on this page · raw message

arch/ppc/platforms/pq2ads.h +4 -0
index 067d9a5..6b26dd3 100644
@@ -13,6 +13,10 @@
 
 #include <asm/ppcboot.h>
 
+#if defined(CONFIG_ADS8272)
+#define BOARD_CHIP_NAME "8272"
+#endif
+
 /* Memory map is configured by the PROM startup.
  * We just map a few things we need.  The CSR is actually 4 byte-wide
  * registers that can be accessed as 8-, 16-, or 32-bit values.
arch/ppc/platforms/pq2ads_pd.h new file +114 -0

114 lines not on this page · raw message

#1 lore raw
Quoted 5 lines · Vitaly Bordug

Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, 866ADS and 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.

Signed-off-by Vitaly Bordug <[email protected]>

Looks great now for the parts I can comment on...

#2 lore raw
In reply to Vitaly Bordug

Hi Vitaly,

OK, I don't really see the advantage of removing the identification stuff, but perhaps I'm missing something. Was there any discussion in the past that I've skipped while reading through the archive?

Because I found the identifcation code really nice. The only problem was that my 8xx didn't support the SVR register.

regards,
Ingo

Quoted 15 lines · Vitaly Bordug

Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, 866ADS and 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.

Signed-off-by Vitaly Bordug <[email protected]>

---
Sincerely,
Vitaly

_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

author
#3 lore raw
Quoted 9 lines · Ingo Hornberger

Hi Vitaly,

OK, I don't really see the advantage of removing the identification stuff, but perhaps I'm missing something. Was there any discussion in the past that I've skipped while reading through the archive?

Because I found the identifcation code really nice. The only problem was that my 8xx didn't support the SVR register.

There was a number of discussions in this regard, which result finally that there no method to identify 8xx board uniquely just using board registers. Hence, we are making identification by board name; the names are presented in syslib/mpc8xx_sys.c. You can see example in this patch.

Quoted 25 lines

regards,
Ingo

Quoted 10 lines · Vitaly Bordug

Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, 866ADS and 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.

Signed-off-by Vitaly Bordug <[email protected]>

---
Sincerely,
Vitaly

Quoted 4 lines

_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Signature · 1 line
Sincerely, Vitaly
#4 lore raw
In reply to Vitaly Bordug
Quoted 4 lines · Vitaly Bordug

+ mpc82xx_fcc1_pdata.dpram_offset =
mpc82xx_fcc2_pdata.dpram_offset = (u32)cpm2_immr->im_dprambase;
+ mpc82xx_fcc1_pdata.fcc_regs_c = mpc82xx_fcc2_pdata.fcc_regs_c
= (u32)cpm2_immr->im_fcc_c;

I'm not sure if this has already been discussed, but what is stopping us from including this in the platform definition files along with the other offsets?

-Matthew

#7 lore raw
In reply to Vitaly Bordug
Quoted 5 lines · Vitaly Bordug

Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, 866ADS and 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.

Signed-off-by Vitaly Bordug <[email protected]>
arch/ppc/platforms/mpc8272ads_setup.c new file +12 -0
new file mode 100644
index 0000000..4f76b1b
@@ -0,0 +1,253 @@
+/*
+ * arch/ppc/platforms/82xx/pq2ads_pd.c
+ *
+ * MPC82xx Board-specific PlatformDevice descriptions
+ *
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <[email protected]>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */

<snip>

+static int __init mpc8272ads_platform_notify(struct device *dev) +{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {"fsl-cpm-fcc", mpc8272ads_fixup_enet_pdata},
+ };
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}

Seems this loop is common to all boards and should be moved to a helper function?

author
#5 lore raw
In reply to Matthew McClintock

Matt,

Quoted 9 lines · Matthew McClintock
Quoted 4 lines · Vitaly Bordug

+ mpc82xx_fcc1_pdata.dpram_offset =
mpc82xx_fcc2_pdata.dpram_offset = (u32)cpm2_immr->im_dprambase;
+ mpc82xx_fcc1_pdata.fcc_regs_c = mpc82xx_fcc2_pdata.fcc_regs_c
= (u32)cpm2_immr->im_fcc_c;

I'm not sure if this has already been discussed, but what is stopping us from including this in the platform definition files along with the other offsets?

IIRC, because these values could vary along the PQ2 family, when all the stuff in pq2_devices.c should be static and applicable to any PQ2 which does have the corresponding device.

Quoted 4 lines

-Matthew

Signature · 1 line
Sincerely, Vitaly
#6 lore raw
Quoted 8 lines · Vitaly Bordug

Matt,

Quoted 6 lines · Matthew McClintock
Quoted 5 lines · Vitaly Bordug

+ mpc82xx_fcc1_pdata.dpram_offset =
mpc82xx_fcc2_pdata.dpram_offset = (u32)cpm2_immr->im_dprambase;
+ mpc82xx_fcc1_pdata.fcc_regs_c =
mpc82xx_fcc2_pdata.fcc_regs_c
= (u32)cpm2_immr->im_fcc_c;

Quoted 4 lines
Quoted 3 lines

I'm not sure if this has already been discussed, but what is stopping us from including this in the platform definition files along with the other offsets?

IIRC, because these values could vary along the PQ2 family, when all the stuff in pq2_devices.c should be static and applicable to any PQ2 which does have the corresponding device.

How much variation is there? I'm not sure how or why it would be different from how we handle the FEC and TSEC on 8540.

- kumar