powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E

arch/powerpc/boot/dts/mpc8315erdb.dts +2 -0

index d3d3097..5997325 100644
@@ -22,6 +22,8 @@
 		serial0 = &serial0;
 		serial1 = &serial1;
 		pci0 = &pci0;
+		pci1 = &pci1;
+		pci2 = &pci2;
 	};
 
 	cpus {

Review

Quoted 5 lines

(quoted diff) +5 -0

+	pci1: pcie@e0009000 {
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		device_type = "pcie";

should just be pci, not pcie

Review

Quoted 3 lines

(quoted diff) +2 -0

+		compatible = "fsl,mpc8315-pcie", "fsl,mpc8314-pcie";
+		reg = <0xe0009000 0x00001000 0xb0000000 0x01000000>;

the size on the 0xb0000000 seems wrong

Review

Quoted 3 lines

(quoted diff) +3 -0

+		ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
+		          0x01000000 0 0x00000000 0xb1000000 0 0x00800000>;
+		bus-range = <0 0>;

normally we have this as <0 255> and assume FW updates it.

Review

Quoted 9 lines

(quoted diff) +8 -0

+		interrupt-map-mask = <0xf800 0 0 7>;
+		interrupt-map = <0 0 0 1 &ipic 1 8
+				 0 0 0 2 &ipic 1 8
+				 0 0 0 3 &ipic 1 8
+				 0 0 0 4 &ipic 1 8>;
+		clock-frequency = <0>;
+		/* cleared by u-boot */
+		status = "not configured";

for pcie nodes we also include the virtual p2p bridge look at the 85xx or 86xx .dts w/pcie in them.

Quoted 6 lines

arch/powerpc/boot/dts/mpc8315erdb.dts line 342

Quoted 4 lines

arch/powerpc/boot/dts/mpc8315erdb.dts +2 -0

+		compatible = "fsl,mpc8315-pcie", "fsl,mpc8314-pcie";
+		reg = <0xe0009000 0x00001000 0xb0000000 0x01000000>;

the size on the 0xb0000000 seems wrong

This is how FSL U-Boots configure the cfg window, and I'm trying to retain the compatibility. Anyway, now Linux maps only the first 4kB of that area, so we don't actually care about this, but dts is still correct for older u-boots. Newer U-Boots might want to correct this value if they want to use other cfg window setup...

Quoted 6 lines

This is how FSL U-Boots configure the cfg window, and I'm trying to retain the compatibility. Anyway, now Linux maps only the first 4kB of that area, so we don't actually care about this, but dts is still correct for older u-boots. Newer U-Boots might want to correct this value if they want to use other cfg window setup...

I'd rather not pollute the .dts with this since I don't believe the open source u-boot supports PCIe on 83xx.

Quoted 7 lines · Anton Vorontsov

Quoted 6 lines

arch/powerpc/boot/dts/mpc8315erdb.dts line 342

Quoted 4 lines

arch/powerpc/boot/dts/mpc8315erdb.dts +2 -0

+		compatible = "fsl,mpc8315-pcie", "fsl,mpc8314-pcie";
+		reg = <0xe0009000 0x00001000 0xb0000000 0x01000000>;

the size on the 0xb0000000 seems wrong

Quoted 5 lines

This is how FSL U-Boots configure the cfg window, and I'm trying to retain the compatibility. Anyway, now Linux maps only the first 4kB of that area, so we don't actually care about this, but dts is still correct for older u-boots. Newer U-Boots might want to correct this value if they want to use other cfg window setup...

I'd rather not pollute the .dts with this

since I don't believe the open
source u-boot supports PCIe on 83xx.

Dear Kumar,

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

Quoted 6 lines

This is how FSL U-Boots configure the cfg window, and I'm trying to retain the compatibility. Anyway, now Linux maps only the first 4kB of that area, so we don't actually care about this, but dts is still correct for older u-boots. Newer U-Boots might want to correct this value if they want to use other cfg window setup...

Quoted 2 lines

I'd rather not pollute the .dts with this since I don't believe the open source u-boot supports PCIe on 83xx.

What exactly do you mean by "open source u-boot"? You don't really mean that there are propriatary (closed source) versions of U-Boot in Freescale, or are you? I iknow that you know that it's GPL, so I guess that was just an unlucky phrase?

Quoted 16 lines · Kumar Gala

Quoted 12 lines · Anton Vorontsov

Quoted 6 lines

arch/powerpc/boot/dts/mpc8315erdb.dts line 342

Quoted 4 lines

arch/powerpc/boot/dts/mpc8315erdb.dts +2 -0

+		compatible = "fsl,mpc8315-pcie", "fsl,mpc8314-pcie";
+		reg = <0xe0009000 0x00001000 0xb0000000 0x01000000>;

the size on the 0xb0000000 seems wrong

This is how FSL U-Boots configure the cfg window, and I'm trying to retain the compatibility. Anyway, now Linux maps only the first 4kB of that area, so we don't actually care about this, but dts is still correct for older u-boots. Newer U-Boots might want to correct this value if they want to use other cfg window setup...

Quoted 1 line

I'd rather not pollute the .dts with this

So you prefer to change the cfg window size to 0x1000?

Quoted 11 lines

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

arch/powerpc/boot/dts/mpc8315erdb.dts line 342

Quoted 2 lines

arch/powerpc/boot/dts/mpc8315erdb.dts +2 -0

+		compatible = "fsl,mpc8315-pcie", "fsl,mpc8314-pcie";
+		reg = <0xe0009000 0x00001000 0xb0000000 0x01000000>;

the size on the 0xb0000000 seems wrong

This is how FSL U-Boots configure the cfg window, and I'm trying to retain the compatibility. Anyway, now Linux maps only the first 4kB of that area, so we don't actually care about this, but dts is still correct for older u-boots. Newer U-Boots might want to correct this value if they want to use other cfg window setup...

Quoted 3 lines

Quoted 1 line

I'd rather not pollute the .dts with this

So you prefer to change the cfg window size to 0x1000?

I'd prefer to drop it (assuming that is reasonable).

Does the PCI-express OF draft spec cover describing cfg space

http://playground.sun.com/1275/proposals/New/516-it.txt

I meant the official u-boot from denx.de vs the one FSL ships w/its boards & BSPs. The BSP u-boot has modifications that don't exist in the denx.de u-boot (as the quality of the code is not up to open source standards).

My statement was to convey that the kernel.org kernel should only worry itself with the denx.de u-boot (w/regards to compatibility).

Quoted 2 lines

My statement was to convey that the kernel.org kernel should only worry itself with the denx.de u-boot (w/regards to compatibility).

Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily).

On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
[...]

Quoted 6 lines

Quoted 2 lines

My statement was to convey that the kernel.org kernel should only worry itself with the denx.de u-boot (w/regards to compatibility).

Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily).

Quoted 4 lines · Scott Wood

Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily).

Just in case, the latest version of this patch set is compatible with the FSL u-boots.

Hello Anton,

Quoted 9 lines · Anton Vorontsov

Quoted 4 lines · Scott Wood

Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily).

Just in case, the latest version of this patch set is compatible with the FSL u-boots.

Up to now, I was testing PCIe with this combo:
- U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board
- dtc 1.1.0
- Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/

That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization.

Is u-boot PCIe initialization required for this kernel patch to work?

Quoted 20 lines · Leon Woestenberg

Hello Anton,

Quoted 9 lines · Anton Vorontsov

Quoted 4 lines · Scott Wood

Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily).

Just in case, the latest version of this patch set is compatible with the FSL u-boots.

Up to now, I was testing PCIe with this combo:
- U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board
- dtc 1.1.0
- Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/

Quoted 3 lines

That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization.

Is u-boot PCIe initialization required for this kernel patch to work?

Yup.

Quoted 17 lines

Quoted 17 lines

Quoted 10 lines

Quoted 5 lines

Why? Unless the BSP u-boots do something insane, I think we should try
to have the upstream kernel boot on the u-boot that comes on the board
(it's not nice to require users to reflash unnecessarily).

Just in case, the latest version of this patch set is compatible with
the FSL u-boots.

Up to now, I was testing PCIe with this combo:
- U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board
- dtc 1.1.0
- Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/

Quoted 5 lines

Quoted 3 lines

That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization.

Is u-boot PCIe initialization required for this kernel patch to work?

Yup.

Really? what for?

Quoted 5 lines · Kumar Gala

Quoted 3 lines

Quoted 1 line

Is u-boot PCIe initialization required for this kernel patch to work?

Yup.

Really? what for?

Hm. U-Boot should initialize SerDes and PCI-E controller (pcie laws, inbound/outbound windows, clocks, etc.)

Though if PCI-E controller wasn't initialized (i.e. board reflashed with the community u-boot), Linux just won't probe the pcie controller:

cfg_bar = in_le32(hose->cfg_data + PEX_OUTWIN0_BAR);

if (!cfg_bar) {
       /* PCI-E isn't configured. */
       ret = -ENODEV;
       goto err1;
}

Or did I misunderstand the question?

Hello Anton,

Quoted 20 lines · Anton Vorontsov

Quoted 5 lines · Kumar Gala

Quoted 3 lines

Quoted 1 line

Is u-boot PCIe initialization required for this kernel patch to work?

Yup.

Really? what for?

Hm. U-Boot should initialize SerDes and PCI-E controller (pcie laws, inbound/outbound windows, clocks, etc.)

Though if PCI-E controller wasn't initialized (i.e. board reflashed with the community u-boot), Linux just won't probe the pcie controller:

cfg_bar = in_le32(hose->cfg_data + PEX_OUTWIN0_BAR);

if (!cfg_bar) {
       /* PCI-E isn't configured. */
       ret = -ENODEV;
       goto err1;
}

Quoted 2 lines

Or did I misunderstand the question?

You understood correctly, thanks for answering.

So to summarize, we need u-boot to initialize the PCIe controller, in order for Linux to further take it over.

What u-boot versions/releases do provide this initialization?

I know the u-boot with the board works, but it's incompatible with recent Linux kernels.

Quoted 4 lines · Leon Woestenberg

So to summarize, we need u-boot to initialize the PCIe controller, in order for Linux to further take it over.

What u-boot versions/releases do provide this initialization?

Only FSL U-Boots so far (i.e. community u-boot + fsl patches).

Quoted 2 lines

I know the u-boot with the board works, but it's incompatible with recent Linux kernels.

We should fix that (if possible).

Hello,

Quoted 9 lines · Anton Vorontsov

On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
[...]

Quoted 6 lines

Quoted 2 lines

My statement was to convey that the kernel.org kernel should only worry itself with the denx.de u-boot (w/regards to compatibility).

Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily).

The u-boot that came with the boards (at least MPC8315E-RDB) is too old for 2.6.25+ kernels:

I have run into this earlier:

http://www.mail-archive.com/[email protected]/msg06551.html