[PATCH] 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 <redacted>

---
Sincerely,
Vitaly

On Mon, Nov 28, 2005 at 08:00:11PM +0300, Vitaly Bordug wrote:

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 <redacted>

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

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

On Mon, 2005-11-28 at 20:00 +0300, Vitaly Bordug wrote:

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 <redacted>

---
Sincerely,
Vitaly


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Ingo Hornberger wrote:

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.

regards,
	Ingo

On Mon, 2005-11-28 at 20:00 +0300, Vitaly Bordug wrote:

quoted

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 <redacted>

---
Sincerely,
Vitaly


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-- 
Sincerely, Vitaly

On Mon, 2005-11-28 at 10:00 -0700, Vitaly Bordug wrote:

+       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

On Mon, Nov 28, 2005 at 08:00:11PM +0300, Vitaly Bordug wrote:

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 <redacted>

diff --git a/arch/ppc/platforms/mpc8272ads_setup.c b/arch/ppc/platforms/mpc8272ads_setup.c
new file mode 100644
index 0000000..4f76b1b
--- /dev/null
+++ b/arch/ppc/platforms/mpc8272ads_setup.c

@@ -0,0 +1,253 @@
+/*
+ * arch/ppc/platforms/82xx/pq2ads_pd.c
+ *
+ * MPC82xx Board-specific PlatformDevice descriptions
+ *
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * 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?

Matt,
Matthew McClintock wrote:

On Mon, 2005-11-28 at 10:00 -0700, Vitaly Bordug wrote:

quoted

+       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.

-Matthew

-- 
Sincerely, Vitaly

On Dec 8, 2005, at 7:40 AM, Vitaly Bordug wrote:

Matt,
Matthew McClintock wrote:

quoted

On Mon, 2005-11-28 at 10:00 -0700, Vitaly Bordug wrote:

quoted

+       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.

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