Add support for Rev. B of PowerPC 440SPe

This is mostly updating the PCI Express code to work with the new core in the Rev. B chip, which unfortunately has different undocumented restrictions on the PLB addresses that can be used from the Rev. A core.

Also, when adding the cputable entry for 440SPe Rev. B, we need to adjust the entry for 440SP Rev. A so that it looks at more bits of the PVR. The 440SPe Rev. B has PVR 53421891, which would have matched the old 440SP pattern of 53xxx891.

Signed-off-by Roland Dreier <[email protected]>

From: Wolfgang Denk <[email protected]>
To: Roland Dreier <[email protected]>
CC: [email protected]
Subject: Re: [PATCH] [POWERPC] Add support for Rev. B of PowerPC 440SPe Date: Mon, 13 Nov 2006 23:27:25 +0100

Quoted 10 lines · In message <[email protected]> you wrote:

This is mostly updating the PCI Express code to work with the new core in the Rev. B chip, which unfortunately has different undocumented restrictions on the PLB addresses that can be used from the Rev. A core.

Also, when adding the cputable entry for 440SPe Rev. B, we need to adjust the entry for 440SP Rev. A so that it looks at more bits of the PVR. The 440SPe Rev. B has PVR 53421891, which would have matched the old 440SP pattern of 53xxx891.

Signed-off-by Roland Dreier <[email protected]>

Just for the record:

This patch is _heavily_ borrowed on code by Rafal Jaworowski; see
http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git;a=commit;h=30e3e3be8863902f508af74fdc61ec9b80756bc0

Please add correct attribution.

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] "In Christianity neither morality nor religion come into contact with
reality at any point." - Friedrich Nietzsche
_______________________________________________
Linuxppc-embedded mailing list [email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

This patch is _heavily_ borrowed on code by Rafal Jaworowski

This is mostly updating the PCI Express code to work with the new core in the Rev. B chip, which unfortunately has different undocumented restrictions on the PLB addresses that can be used from the Rev. A core.

Also, when adding the cputable entry for 440SPe Rev. B, we need to adjust the entry for 440SP Rev. A so that it looks at more bits of the PVR. The 440SPe Rev. B has PVR 53421891, which would have matched the old 440SP pattern of 53xxx891.

This is a cleaned up version of the original work done by Rafal Jaworowski <[email protected]>, who actually suffered through figuring out how to avoid the Rev. B chip locking up when using PCIe.

Signed-off-by Roland Dreier <[email protected]>

arch/ppc/syslib/ppc440spe_pcie.c +18 -0

+static void ppc440spe_setup_utl(int port)
+{
+	void __iomem *utl_base;
+
+	/*
+	 * Map UTL registers at 0xc_1000_0n00
+	 */
+	switch (port) {
+	case 0:
+		mtdcr(DCRN_PEGPL_REGBAH(PCIE0), 0x0000000c);
+		mtdcr(DCRN_PEGPL_REGBAL(PCIE0), 0x10000000);
+		mtdcr(DCRN_PEGPL_REGMSK(PCIE0), 0x00007001);
+		mtdcr(DCRN_PEGPL_SPECIAL(PCIE0), 0x68782800);
+		break;
+
+	case 1:
+		mtdcr(DCRN_PEGPL_REGBAH(PCIE1), 0x0000000c);
+		mtdcr(DCRN_PEGPL_REGBAL(PCIE1), 0x10001000);

arch/ppc/syslib/ppc440spe_pcie.c +14 -6

 	switch (port) {
 	case 0:
-		mtdcr(DCRN_PEGPL_CFGBAH(PCIE0), 0x0000000c);
-		mtdcr(DCRN_PEGPL_CFGBAL(PCIE0), 0x40000000);
+		if (core_rev == REV_A) {
+			mtdcr(DCRN_PEGPL_CFGBAH(PCIE0), 0x0000000c);
+			mtdcr(DCRN_PEGPL_CFGBAL(PCIE0), 0x40000000);
+		} else {
+			mtdcr(DCRN_PEGPL_CFGBAH(PCIE0), 0x0000000d);
+			mtdcr(DCRN_PEGPL_CFGBAL(PCIE0), 0x00000000);
+		}
 		mtdcr(DCRN_PEGPL_CFGMSK(PCIE0), 0xe0000001); /* 512MB region, valid */
 		break;
 
 	case 1:
-		mtdcr(DCRN_PEGPL_CFGBAH(PCIE1), 0x0000000c);
-		mtdcr(DCRN_PEGPL_CFGBAL(PCIE1), 0x80000000);
+		if (core_rev == REV_A) {
+			mtdcr(DCRN_PEGPL_CFGBAH(PCIE1), 0x0000000c);
+			mtdcr(DCRN_PEGPL_CFGBAL(PCIE1), 0x80000000);
+		} else {
+			mtdcr(DCRN_PEGPL_CFGBAH(PCIE1), 0x0000000d);
+			mtdcr(DCRN_PEGPL_CFGBAL(PCIE1), 0x20000000);
+		}
 		mtdcr(DCRN_PEGPL_CFGMSK(PCIE1), 0xe0000001); /* 512MB region, valid */
 		break;
 
 	case 2:
-		mtdcr(DCRN_PEGPL_CFGBAH(PCIE2), 0x0000000c);
-		mtdcr(DCRN_PEGPL_CFGBAL(PCIE2), 0xc0000000);

Can we get rid of this switch as well?

There are other places like this in the patch but I think you got my idea :).

I think there have to be switches (or equivalently, look-up tables) since there's no regularity in where the DCRs/SDRs for the different PCIe ports are.

I think look-up tables are fine. It's not a fast path, is it?

Quoted 1 line

I think look-up tables are fine. It's not a fast path, is it?

Nope, that would be fine. I'll definitely cut down on the code duplication -- I'm just not sure what will end up being cleanest. I don't see that much difference between a switch and a look-up table for finding the base DCR index for a particular port.

OK, I was just wanted to make sure you were aware that mfdcr/mtdcr supported run-time specified DCR number (from that code it wasn't clear).