[PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[Zhang Wei]

Hi, Paul,

The below 5 patches add the support for MPC8641 rev 2.0 silicon and MPC8641HPCN board 2.0.

  [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.
  [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
  [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
  [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
  [PATCH 5/5] Set IDE in ULI1575 to not native mode.

The MPC8641 rev 2.0 silicon fix the PCI/PCI-Express errata in rev 1.0. And the rev 1.0 silicon is end of life. So the dts tree and codes should be changes. Codes which are not compatible with PCI/PCI-Express specifications are removed. Some minor issues are fixed.

Thanks!

Best Regards,
Zhang Wei

[PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.

[Zhang Wei]

Remove the errata fix codes for MPC8641 silicon ver 1.0 which
is end of life.

The MPC8641 silicon ver 1.0 is not fully support PCI/PCI Express
specifications. The revision 2.0 fixes all of these errata
and the rev 1.0 silicon is end of life. So errata codes are removed.

Now, The chip is full compatible with PCI/PCI Express
specifications. The generic PCI code is used.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
---
 arch/powerpc/Kconfig                  |    3 +--
 arch/powerpc/platforms/86xx/mpc86xx.h |    6 ------
 arch/powerpc/platforms/86xx/pci.c     |   10 +---------
 3 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index f768de3..42c2c57 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -175,7 +175,6 @@ config PPC_86xx
 	bool "Freescale 86xx"
 	select 6xx
 	select FSL_SOC
-	select FSL_PCIE
 	select PPC_FPU
 	select ALTIVEC
 	help
@@ -647,7 +646,7 @@ config FSL_SOC
 
 config FSL_PCIE
 	bool
-	depends on PPC_86xx
+	depends on PPC_85xx
 
 # Yes MCA RS/6000s exist but Linux-PPC does not currently support any
 config MCA
diff --git a/arch/powerpc/platforms/86xx/mpc86xx.h b/arch/powerpc/platforms/86xx/mpc86xx.h
index 2834462..740b300 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx.h
+++ b/arch/powerpc/platforms/86xx/mpc86xx.h
@@ -19,12 +19,6 @@ extern int add_bridge(struct device_node *dev);
 
 extern int mpc86xx_exclude_device(u_char bus, u_char devfn);
 
-extern void setup_indirect_pcie(struct pci_controller *hose,
-				       u32 cfg_addr, u32 cfg_data);
-extern void setup_indirect_pcie_nomap(struct pci_controller *hose,
-					     void __iomem *cfg_addr,
-					     void __iomem *cfg_data);
-
 extern void __init mpc86xx_smp_init(void);
 
 #endif	/* __MPC86XX_H__ */
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 8235c56..7efae7c 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -133,18 +133,10 @@ mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
 	early_write_config_word(hose, 0, 0, PCI_COMMAND, cmd);
 
 	early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0x80);
-
-	/* PCIE Bus, Fix the MPC8641D host bridge's location to bus 0xFF. */
-	early_read_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, &temps);
-	temps = (temps & 0xff000000) | (0xff) | (0x0 << 8) | (0xfe << 16);
-	early_write_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, temps);
 }
 
 int mpc86xx_exclude_device(u_char bus, u_char devfn)
 {
-	if (bus == 0 && PCI_SLOT(devfn) == 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
-
 	return PCIBIOS_SUCCESSFUL;
 }
 
@@ -178,7 +170,7 @@ int __init add_bridge(struct device_node *dev)
 	hose->first_busno = bus_range ? bus_range[0] : 0x0;
 	hose->last_busno = bus_range ? bus_range[1] : 0xfe;
 
-	setup_indirect_pcie(hose, rsrc.start, rsrc.start + 0x4);
+	setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4);
 
 	/* Setup the PCIE host controller. */
 	mpc86xx_setup_pcie(hose, rsrc.start, rsrc.end - rsrc.start + 1);
-- 
1.5.1

[PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Zhang Wei]

Add uli1575 pci-bridge sector. It fixes the issue of ULI1575 not found on rev.2 board.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
 arch/powerpc/boot/dts/mpc8641_hpcn.dts      |    6 ++++++
 arch/powerpc/boot/dts/mpc8641_hpcn_srio.dts |    6 ++++++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 260b264..04626b1 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -297,6 +297,12 @@
 				interrupts = <49 2>;
 				interrupt-parent = <&mpic>;
 			};
+			uli1575: uli1575@100 {
+				reg = <0 0 0 0 0>;
+				pci_bridge@200 {
+					reg = <0 0 0 0 0>;
+				};
+			};
 
 		};
 
-- 
1.5.1

[PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Zhang Wei]

Float the pci bus number on MPC8641HPCN board.
For example, PCI hose 1 bus range is from 0 to 2, the PCI hose 2 bus
range will start from 3.
Add the pci-express link training stats check. It avoid the system halt
while the link training is fault.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
---
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |    1 +
 arch/powerpc/platforms/86xx/pci.c          |   23 ++++++++++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index ae5714f..2dacc33 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -358,6 +358,7 @@ mpc86xx_hpcn_setup_arch(void)
 	}
 
 #ifdef CONFIG_PCI
+	pci_assign_all_buses = 1;
 	for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
 		add_bridge(np);
 
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 7efae7c..5612f6a 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -122,7 +122,6 @@ static void __init
 mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
 {
 	u16 cmd;
-	unsigned int temps;
 
 	DBG("PCIE host controller register offset 0x%08x, size 0x%08x.\n",
 			pcie_offset, pcie_size);
@@ -137,9 +136,23 @@ mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
 
 int mpc86xx_exclude_device(u_char bus, u_char devfn)
 {
+	struct pci_controller *hose;
+
+	hose = pci_bus_to_hose(bus);
+	if (unlikely(!hose))
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/* Correcting the hose->bus_offset value. */
+	out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
+					- hose->bus_offset) << 16));
+	if (unlikely(in_le32(hose->cfg_data) == 0xffffffff))
+		hose->bus_offset = hose->bus_offset ? 0 : hose->first_busno;
+
 	return PCIBIOS_SUCCESSFUL;
 }
 
+#define PCIE_LTSSM	0x04000004	/* PCIe Link Training and Status */
+#define PCIE_LTSSM_L0	0x16		/* L0 state */
 int __init add_bridge(struct device_node *dev)
 {
 	int len;
@@ -148,12 +161,20 @@ int __init add_bridge(struct device_node *dev)
 	const int *bus_range;
 	int has_address = 0;
 	int primary = 0;
+	void *pcicfg_addr;
 
 	DBG("Adding PCIE host bridge %s\n", dev->full_name);
 
 	/* Fetch host bridge registers address */
 	has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
 
+	/* Probe the hose link training status */
+	pcicfg_addr = ioremap(rsrc.start, 0x1000);
+	out_be32(pcicfg_addr, 0x80000000 | PCIE_LTSSM);
+	if (in_le16(pcicfg_addr + 4) < PCIE_LTSSM_L0)
+		return -ENXIO;
+	iounmap(pcicfg_addr);
+
 	/* Get bus range if any */
 	bus_range = of_get_property(dev, "bus-range", &len);
 	if (bus_range == NULL || len < 2 * sizeof(int))
-- 
1.5.1

[PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.

[Zhang Wei]

Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
Now, the children bus could use the I/O resource of the host bridge.

Note: The 0x7010 is the device ID of host bridge for MPC8641 and
0x7011 is the device ID of host bridge fro MPC8641D.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 2dacc33..eb2bc99 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -319,6 +319,11 @@ static void __devinit quirk_uli5229(struct pci_dev *dev)
 	pci_write_config_word(dev, 0x4a, temp);
 }
 
+static void __devinit quirk_mpc8641_transparent(struct pci_dev *dev)
+{
+	dev->transparent = 1;
+}
+
 static void __devinit early_uli5249(struct pci_dev *dev)
 {
 	unsigned char temp;
@@ -333,6 +338,8 @@ static void __devinit early_uli5249(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575, quirk_uli1575);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5288, quirk_uli5288);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229, quirk_uli5229);
+DECLARE_PCI_FIXUP_HEADER(0x1957, 0x7010, quirk_mpc8641_transparent);
+DECLARE_PCI_FIXUP_HEADER(0x1957, 0x7011, quirk_mpc8641_transparent);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
 #endif /* CONFIG_PCI */
 
-- 
1.5.1

[PATCH 5/5] Set IDE in ULI1575 to not native mode.

[Zhang Wei]

Set IDE in ULI1575 to not 100% native mode, which forces
the IDE driver to probe the irq itself.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index eb2bc99..2a2dea7 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -314,6 +314,7 @@ static void __devinit quirk_uli5229(struct pci_dev *dev)
 {
 	unsigned short temp;
 	pci_write_config_word(dev, 0x04, 0x0405);
+	dev->class &= ~0x5;
 	pci_read_config_word(dev, 0x4a, &temp);
 	temp |= 0x1000;
 	pci_write_config_word(dev, 0x4a, temp);
-- 
1.5.1

Re: [PATCH 5/5] Set IDE in ULI1575 to not native mode.

[Jon Loeliger]

On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Set IDE in ULI1575 to not 100% native mode, which forces
> the IDE driver to probe the irq itself.
> 
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>

Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>

Re: [PATCH 5/5] Set IDE in ULI1575 to not native mode.

[Kumar Gala]

On May 21, 2007, at 10:38 PM, Zhang Wei wrote:

> Set IDE in ULI1575 to not 100% native mode, which forces
> the IDE driver to probe the irq itself.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>

What causes this to be needed?

- k

> ---
>  arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/ 
> powerpc/platforms/86xx/mpc86xx_hpcn.c
> index eb2bc99..2a2dea7 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -314,6 +314,7 @@ static void __devinit quirk_uli5229(struct  
> pci_dev *dev)
>  {
>  	unsigned short temp;
>  	pci_write_config_word(dev, 0x04, 0x0405);
> +	dev->class &= ~0x5;
>  	pci_read_config_word(dev, 0x4a, &temp);
>  	temp |= 0x1000;
>  	pci_write_config_word(dev, 0x4a, temp);
> -- 
> 1.5.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH 5/5] Set IDE in ULI1575 to not native mode.

[Zhang Wei-r63237]

Hi,

> > Set IDE in ULI1575 to not 100% native mode, which forces
> > the IDE driver to probe the irq itself.
> >
> > Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
>=20
> What causes this to be needed?
>=20

If the driver does not probe the irq itself, the driver will get wrong
irq for lagecy IDE device.

Thanks!
Wei.

RE: [PATCH 5/5] Set IDE in ULI1575 to not native mode.

[Benjamin Herrenschmidt]

On Wed, 2007-05-30 at 10:25 +0800, Zhang Wei-r63237 wrote:
> 
> If the driver does not probe the irq itself, the driver will get wrong
> irq for lagecy IDE device.

Sorry, I didn't understand... care to explain in more details ?

Ben.

RE: [PATCH 5/5] Set IDE in ULI1575 to not native mode.

[Zhang Wei-r63237]

Hi, Ben,

I agree with your comments -- 'Native mode should generally work
better'.
In 100% native mode, the driver will get irq itself. So we need this
patch.

Thanks!
Wei.

>=20
> Sorry, I didn't understand... care to explain in more details ?
>=20
> Ben.
>=20
>=20
>=20

Re: [PATCH 5/5] Set IDE in ULI1575 to not native mode.

[Benjamin Herrenschmidt]

On Tue, 2007-05-29 at 15:50 -0500, Kumar Gala wrote:
> 
> > Set IDE in ULI1575 to not 100% native mode, which forces
> > the IDE driver to probe the irq itself.
> >
> > Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> 
> What causes this to be needed?

Yeah, that looks dodgy. Native mode should generally work better

Ben.

Re: [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.

[Jon Loeliger]

On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
> Now, the children bus could use the I/O resource of the host bridge.
> 
> Note: The 0x7010 is the device ID of host bridge for MPC8641 and
> 0x7011 is the device ID of host bridge fro MPC8641D.
> 
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>

Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Wade Farnsworth]

On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
>  int mpc86xx_exclude_device(u_char bus, u_char devfn)
>  {
> +	struct pci_controller *hose;
> +
> +	hose = pci_bus_to_hose(bus);
> +	if (unlikely(!hose))
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +	/* Correcting the hose->bus_offset value. */
> +	out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
> +					- hose->bus_offset) << 16));
> +	if (unlikely(in_le32(hose->cfg_data) == 0xffffffff))
> +		hose->bus_offset = hose->bus_offset ? 0 : hose->first_busno;
> +
>  	return PCIBIOS_SUCCESSFUL;
>  }

What is the purpose of this code and why put it in
mpc86xx_exclude_device?

--Wade

RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Zhang Wei-r63237]

Hi, Wade,

That's a good question.

The ppc_md.exclude_device() function will be called before PCI config
access in indirect_read/write_config() of the file
arch/powerpc/sysdev/indirect_pci.c. If the hose->bus_offset value is 0,
the primary bus number register of the host must be hose->first_busno.
Otherwise, if the host primary bus number register is 0, the
hose->bus_offset must be the same value of hose->first_buseno.

When the pci scan bus, the bridge will be scaned twice. When the second
scan is finished, the host primary bus number register will be write to
hose->first_busno. The PCI bus(not the first PCI host) access will be
wrong in the later access. I'll check it and correct the
hose->bus_offset value in these codes.

Thanks!
Wei

> -----Original Message-----
> From: Wade Farnsworth [mailto:wfarnsworth@mvista.com]=20
> Subject: Re: [PATCH 3/5] Float the pci bus number on=20
> MPC8641HPCN board.
>=20
> On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
> >  int mpc86xx_exclude_device(u_char bus, u_char devfn)
> >  {
> > +	struct pci_controller *hose;
> > +
> > +	hose =3D pci_bus_to_hose(bus);
> > +	if (unlikely(!hose))
> > +		return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > +	/* Correcting the hose->bus_offset value. */
> > +	out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
> > +					- hose->bus_offset) << 16));
> > +	if (unlikely(in_le32(hose->cfg_data) =3D=3D 0xffffffff))
> > +		hose->bus_offset =3D hose->bus_offset ? 0 :=20
> hose->first_busno;
> > +
> >  	return PCIBIOS_SUCCESSFUL;
> >  }
>=20
> What is the purpose of this code and why put it in
> mpc86xx_exclude_device?
>=20
> --Wade
>=20
>=20

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Kumar Gala]

On May 22, 2007, at 10:35 PM, Zhang Wei-r63237 wrote:

> Hi, Wade,
>
> That's a good question.
>
> The ppc_md.exclude_device() function will be called before PCI config
> access in indirect_read/write_config() of the file
> arch/powerpc/sysdev/indirect_pci.c. If the hose->bus_offset value  
> is 0,
> the primary bus number register of the host must be hose->first_busno.
> Otherwise, if the host primary bus number register is 0, the
> hose->bus_offset must be the same value of hose->first_buseno.
>
> When the pci scan bus, the bridge will be scaned twice. When the  
> second
> scan is finished, the host primary bus number register will be  
> write to
> hose->first_busno. The PCI bus(not the first PCI host) access will be
> wrong in the later access. I'll check it and correct the
> hose->bus_offset value in these codes.

Can this be fixed by just setting hose->bus_offset in add_bridge?

Doing this in exclude is very bad.

- k

>> -----Original Message-----
>> From: Wade Farnsworth [mailto:wfarnsworth@mvista.com]
>> Subject: Re: [PATCH 3/5] Float the pci bus number on
>> MPC8641HPCN board.
>>
>> On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
>>>  int mpc86xx_exclude_device(u_char bus, u_char devfn)
>>>  {
>>> +	struct pci_controller *hose;
>>> +
>>> +	hose = pci_bus_to_hose(bus);
>>> +	if (unlikely(!hose))
>>> +		return PCIBIOS_DEVICE_NOT_FOUND;
>>> +
>>> +	/* Correcting the hose->bus_offset value. */
>>> +	out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
>>> +					- hose->bus_offset) << 16));
>>> +	if (unlikely(in_le32(hose->cfg_data) == 0xffffffff))
>>> +		hose->bus_offset = hose->bus_offset ? 0 :
>> hose->first_busno;
>>> +
>>>  	return PCIBIOS_SUCCESSFUL;
>>>  }
>>
>> What is the purpose of this code and why put it in
>> mpc86xx_exclude_device?
>>
>> --Wade
>>
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Zhang Wei-r63237]

Hi, Kumar,=20

>=20
> Can this be fixed by just setting hose->bus_offset in add_bridge?
>=20
> Doing this in exclude is very bad.

That's my original doing. If there a PCI bridge card be pluged into PCI
slot of hose0, I can not ensue the bus_offset number of hose1.

Wei.

>=20
> - k
>=20
> >> -----Original Message-----
> >> From: Wade Farnsworth [mailto:wfarnsworth@mvista.com]
> >> Subject: Re: [PATCH 3/5] Float the pci bus number on
> >> MPC8641HPCN board.
> >>
> >> On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
> >>>  int mpc86xx_exclude_device(u_char bus, u_char devfn)
> >>>  {
> >>> +	struct pci_controller *hose;
> >>> +
> >>> +	hose =3D pci_bus_to_hose(bus);
> >>> +	if (unlikely(!hose))
> >>> +		return PCIBIOS_DEVICE_NOT_FOUND;
> >>> +
> >>> +	/* Correcting the hose->bus_offset value. */
> >>> +	out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
> >>> +					- hose->bus_offset) << 16));
> >>> +	if (unlikely(in_le32(hose->cfg_data) =3D=3D 0xffffffff))
> >>> +		hose->bus_offset =3D hose->bus_offset ? 0 :
> >> hose->first_busno;
> >>> +
> >>>  	return PCIBIOS_SUCCESSFUL;
> >>>  }
> >>
> >> What is the purpose of this code and why put it in
> >> mpc86xx_exclude_device?
> >>
> >> --Wade
> >>
> >>
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Kumar Gala]

On May 31, 2007, at 9:01 PM, Zhang Wei-r63237 wrote:

> Hi, Kumar,
>
>>
>> Can this be fixed by just setting hose->bus_offset in add_bridge?
>>
>> Doing this in exclude is very bad.
>
> That's my original doing. If there a PCI bridge card be pluged into  
> PCI
> slot of hose0, I can not ensue the bus_offset number of hose1.

Ok, but can't we use hose0's last_busno and use that set hose1- 
 >first_busno & hose1->bus_offset?

- k

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Paul Mackerras]

Kumar Gala writes:

> > That's my original doing. If there a PCI bridge card be pluged into  
> > PCI
> > slot of hose0, I can not ensue the bus_offset number of hose1.
> 
> Ok, but can't we use hose0's last_busno and use that set hose1- 
>  >first_busno & hose1->bus_offset?

Why do the bus numbers for hose0 and hose1 have to have any relation
to each other at all?  Aren't they separate PCI domains?

Paul.

RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Zhang Wei-r63237]

Hi, Paul,=20

> -----Original Message-----
> From: Paul Mackerras [mailto:paulus@samba.org]=20
>=20
> Kumar Gala writes:
>=20
> > > That's my original doing. If there a PCI bridge card be=20
> pluged into =20
> > > PCI
> > > slot of hose0, I can not ensue the bus_offset number of hose1.
> >=20
> > Ok, but can't we use hose0's last_busno and use that set hose1-=20
> >  >first_busno & hose1->bus_offset?
>=20
> Why do the bus numbers for hose0 and hose1 have to have any relation
> to each other at all?  Aren't they separate PCI domains?

There are lots of lagacy PCI codes in kernel, such as
pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
pci_bus_to_hose() can not return the correct hose. And there will effect
/proc/pci and lspci tools.

Thanks!
Wei.

RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Benjamin Herrenschmidt]

On Fri, 2007-06-01 at 14:45 +0800, Zhang Wei-r63237 wrote:
> There are lots of lagacy PCI codes in kernel, such as
> pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
> pci_bus_to_hose() can not return the correct hose. And there will
> effect
> /proc/pci and lspci tools.

More specifically...

Overlapping bus numbers on separate domains work... on 64 bits :-) The
32 bits PCI code assumes non-overlapping numbers. The main reason for
that historically was that back then, domains didn't work well.

The second reasons why I didn't actually fix it is that turning on full
domain support had (and probably still has) the nasty habit of breaking
the X server :-( X is full of most horrible hacks for PCI and it will be
terminally broken until they finally merge the pci-rework branch that
Ian Romanick's been working on for some time now.

One of these days, one of us will finally tackle merging 32 and 64 bits
PCI code (and fix both of them while at it to better use the generic
code, which involves fixing issues in the said generic code too :-) at
which point I'll enable full domain support for 32 bits as well, with an
option to degrade it to bus number remapping.

Ben.

RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Zhang Wei-r63237]

Hi, Ben,

> One of these days, one of us will finally tackle merging 32=20
> and 64 bits
> PCI code (and fix both of them while at it to better use the generic
> code, which involves fixing issues in the said generic code too :-) at
> which point I'll enable full domain support for 32 bits as=20
> well, with an
> option to degrade it to bus number remapping.
>=20

Do you want to implement vbus such as virq? :)

Cheers!
Wei.

RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Benjamin Herrenschmidt]

On Fri, 2007-06-01 at 15:53 +0800, Zhang Wei-r63237 wrote:
> 
> Do you want to implement vbus such as virq? :) 

Not really :-)

We do remap on powermac today, or rather, re-assign, though, to ensure
numbers don't overlap (powermacs have up to 3 domains that the firmware
set to overlapping bus numbers)

Ben

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Matt Sealey]

Re enabling proper domain support on 32-bit... now, now, now please!

X guys won't merge in code, we've been punished by both sides on Pegasos
for nearly 12 months now after there's been a bunch of misguided attempts
to 'fix' domain support in X. The real fix is in the kernel to make it
very clear that domains and proper, per-domain bus numbering (not
global bus numbering) and suchlike is the standard like it is on SPARC
and PPC64 and IA64.

If ppc32 suddenly goes the way of these, X guys will fix it, there will
be patches to work against this kernel, even if they have to detect the
kernel version to do it or look at a procfs or sysfs entry to fix up
their dumb pci scanning code.

I don't think stalling on it "because of X" is right. Fix Linux, X will
follow, because it really has to.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-01 at 14:45 +0800, Zhang Wei-r63237 wrote:
>> There are lots of lagacy PCI codes in kernel, such as
>> pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
>> pci_bus_to_hose() can not return the correct hose. And there will
>> effect
>> /proc/pci and lspci tools.
> 
> More specifically...
> 
> Overlapping bus numbers on separate domains work... on 64 bits :-) The
> 32 bits PCI code assumes non-overlapping numbers. The main reason for
> that historically was that back then, domains didn't work well.
> 
> The second reasons why I didn't actually fix it is that turning on full
> domain support had (and probably still has) the nasty habit of breaking
> the X server :-( X is full of most horrible hacks for PCI and it will be
> terminally broken until they finally merge the pci-rework branch that
> Ian Romanick's been working on for some time now.
> 
> One of these days, one of us will finally tackle merging 32 and 64 bits
> PCI code (and fix both of them while at it to better use the generic
> code, which involves fixing issues in the said generic code too :-) at
> which point I'll enable full domain support for 32 bits as well, with an
> option to degrade it to bus number remapping.
> 
> Ben.
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Jon Loeliger]

On Fri, 2007-06-01 at 11:35, Matt Sealey wrote:
> Re enabling proper domain support on 32-bit... now, now, now please!
> 
> X guys won't merge in code, we've been punished by both sides on Pegasos
> for nearly 12 months now after there's been a bunch of misguided attempts
> to 'fix' domain support in X. The real fix is in the kernel to make it
> very clear that domains and proper, per-domain bus numbering (not
> global bus numbering) and suchlike is the standard like it is on SPARC
> and PPC64 and IA64.
> 
> If ppc32 suddenly goes the way of these, X guys will fix it, there will
> be patches to work against this kernel, even if they have to detect the
> kernel version to do it or look at a procfs or sysfs entry to fix up
> their dumb pci scanning code.
> 
> I don't think stalling on it "because of X" is right. Fix Linux, X will
> follow, because it really has to.

OK.  Let me interpret this for my (8641) case:

These two lines of quirky code in _exclude_device()
are not ideal, but they adjust for a PCI systemic 
problem that isn't going to be fixed any time soon.

Therefore, I will go ahead and repost my PCI patch
series to get PCI-E working again on 8641, and pointed
in the right direction so we can merge in the support
for 8548 and 8544 as follow ups.

We (collectively) will then address the systemic PCI
problem with 32-bit systems later.

Thanks,
jdl

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Benjamin Herrenschmidt]

On Fri, 2007-06-01 at 11:47 -0500, Jon Loeliger wrote:
> 
> Therefore, I will go ahead and repost my PCI patch
> series to get PCI-E working again on 8641, and pointed
> in the right direction so we can merge in the support
> for 8548 and 8544 as follow ups.
> 
> We (collectively) will then address the systemic PCI
> problem with 32-bit systems later. 

Exactly.

Cheers,
Ben.

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Benjamin Herrenschmidt]

On Fri, 2007-06-01 at 17:35 +0100, Matt Sealey wrote:
> Re enabling proper domain support on 32-bit... now, now, now please!
> 
> X guys won't merge in code, we've been punished by both sides on Pegasos
> for nearly 12 months now after there's been a bunch of misguided attempts
> to 'fix' domain support in X. 

Well, I have commit rights on X git :-) But the current X code is too
hopeless to warrant anything but a quick hack which I don't want to do.

> The real fix is in the kernel to make it
> very clear that domains and proper, per-domain bus numbering (not
> global bus numbering) and suchlike is the standard like it is on SPARC
> and PPC64 and IA64.

Well... if the real fix means suddenly nobody can use X ...  I'm sorry
but I won't inflict that one the remaining lots of 32 bits PowerMac (and
Pegasos) users. Not until there is a fixed X available. Once Ian's work
on pci-rework X.org branch is finally merged with the trunk then life
will be better for everybody.

> If ppc32 suddenly goes the way of these, X guys will fix it, there will
> be patches to work against this kernel, even if they have to detect the
> kernel version to do it or look at a procfs or sysfs entry to fix up
> their dumb pci scanning code.

X guys would probably expect me to fix it yeah :-)

> I don't think stalling on it "because of X" is right. Fix Linux, X will
> follow, because it really has to.

Ugh ... I don't think so.

Cheers,
Ben.

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Segher Boessenkool]

>> The real fix is in the kernel to make it
>> very clear that domains and proper, per-domain bus numbering (not
>> global bus numbering) and suchlike is the standard like it is on SPARC
>> and PPC64 and IA64.
>
> Well... if the real fix means suddenly nobody can use X ...  I'm sorry
> but I won't inflict that one the remaining lots of 32 bits PowerMac 
> (and
> Pegasos) users. Not until there is a fixed X available. Once Ian's work
> on pci-rework X.org branch is finally merged with the trunk then life
> will be better for everybody.

In the meantime, you could have a kernel config option
selecting between "good new" and "bad old" ppc32 PCI
stack.  At the very least it will make it easier for both
kernel and X people to test their stuff.  Also it will
allow users to switch to the bad old but working stack
if things don't go too smoothly during the transition.


Segher

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Benjamin Herrenschmidt]

On Sat, 2007-06-02 at 10:36 +0200, Segher Boessenkool wrote:
> In the meantime, you could have a kernel config option
> selecting between "good new" and "bad old" ppc32 PCI
> stack.  At the very least it will make it easier for both
> kernel and X people to test their stuff.  Also it will
> allow users to switch to the bad old but working stack
> if things don't go too smoothly during the transition.

Could be a boot or platform option.. basically enabling unconditional
outputing of domains ... plus a few other things like removing iobase
syscall etc..

Ben.

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Kumar Gala]

On Jun 1, 2007, at 1:45 AM, Zhang Wei-r63237 wrote:

> Hi, Paul,
>
>> -----Original Message-----
>> From: Paul Mackerras [mailto:paulus@samba.org]
>>
>> Kumar Gala writes:
>>
>>>> That's my original doing. If there a PCI bridge card be
>> pluged into
>>>> PCI
>>>> slot of hose0, I can not ensue the bus_offset number of hose1.
>>>
>>> Ok, but can't we use hose0's last_busno and use that set hose1-
>>>> first_busno & hose1->bus_offset?
>>
>> Why do the bus numbers for hose0 and hose1 have to have any relation
>> to each other at all?  Aren't they separate PCI domains?
>
> There are lots of lagacy PCI codes in kernel, such as
> pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
> pci_bus_to_hose() can not return the correct hose. And there will  
> effect
> /proc/pci and lspci tools.


So looking at the code it looks like pci_assign_all_buses should  
handle numbering the busses properly when we scan the busses, so  
what's the issue that causes that not to be correct?

- k

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Benjamin Herrenschmidt]

On Fri, 2007-06-01 at 14:58 -0500, Kumar Gala wrote:
> 
> So looking at the code it looks like pci_assign_all_buses should  
> handle numbering the busses properly when we scan the busses, so  
> what's the issue that causes that not to be correct? 

Yeah, that's what powermac uses... Any reason it wouldn't work ?

Ben.

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Jon Loeliger]

On Fri, 2007-06-01 at 18:28, Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-01 at 14:58 -0500, Kumar Gala wrote:
> > 
> > So looking at the code it looks like pci_assign_all_buses should  
> > handle numbering the busses properly when we scan the busses, so  
> > what's the issue that causes that not to be correct? 
> 
> Yeah, that's what powermac uses... Any reason it wouldn't work ?
> 
> Ben.

Empirical testing says it doesn't work.

jdl

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Benjamin Herrenschmidt]

On Mon, 2007-06-04 at 14:00 -0500, Jon Loeliger wrote:
> On Fri, 2007-06-01 at 18:28, Benjamin Herrenschmidt wrote:
> > On Fri, 2007-06-01 at 14:58 -0500, Kumar Gala wrote:
> > > 
> > > So looking at the code it looks like pci_assign_all_buses should  
> > > handle numbering the busses properly when we scan the busses, so  
> > > what's the issue that causes that not to be correct? 
> > 
> > Yeah, that's what powermac uses... Any reason it wouldn't work ?
> > 
> > Ben.
> 
> Empirical testing says it doesn't work.

You may also need to tweak pcibios_assign_bus_offset to bump it to a
higher value. There are issues when renumbering bus numbers when during
the probe, a bus is renumbered to the same number as a not-yet probed
bridge on the same segment.

That is fixed on powermac by adding an artificial "offset" of 16 between
bus numbers of different domains via this offset variable.

Ben.

RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Zhang Wei-r63237]

Hi, Kumar,=20

>=20
> On May 31, 2007, at 9:01 PM, Zhang Wei-r63237 wrote:
>=20
> > Hi, Kumar,
> >
> >>
> >> Can this be fixed by just setting hose->bus_offset in add_bridge?
> >>
> >> Doing this in exclude is very bad.
> >
> > That's my original doing. If there a PCI bridge card be=20
> pluged into =20
> > PCI
> > slot of hose0, I can not ensue the bus_offset number of hose1.
>=20
> Ok, but can't we use hose0's last_busno and use that set hose1-=20
>  >first_busno & hose1->bus_offset?

When in add_bridge(), the pci bus scan is not start, so we do not know
hose0's last_busno.

Thanks!
Wei.

Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

[Jon Loeliger]

On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Float the pci bus number on MPC8641HPCN board.
> For example, PCI hose 1 bus range is from 0 to 2, the PCI hose 2 bus
> range will start from 3.
> Add the pci-express link training stats check. It avoid the system halt
> while the link training is fault.
> 
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Acked-by: Roy Zang <tie-fei.zang@freescale.com>
> ---

Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>

Re: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[xianghua xiao]

where is the new uli1575 node referred except for this added snippet?
thanks,
xianghua

Zhang Wei wrote:

>Add uli1575 pci-bridge sector. It fixes the issue of ULI1575 not found on rev.2 board.
>
>Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
>---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts      |    6 ++++++
> arch/powerpc/boot/dts/mpc8641_hpcn_srio.dts |    6 ++++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
>diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>index 260b264..04626b1 100644
>--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>@@ -297,6 +297,12 @@
> 				interrupts = <49 2>;
> 				interrupt-parent = <&mpic>;
> 			};
>+			uli1575: uli1575@100 {
>+				reg = <0 0 0 0 0>;
>+				pci_bridge@200 {
>+					reg = <0 0 0 0 0>;
>+				};
>+			};
> 
> 		};
> 
>  
>

RE: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Zhang Wei-r63237]

Hi, Xianghua,=20

> -----Original Message-----
> From: xianghua xiao [mailto:x.xiao@freescale.com]=20
> Subject: Re: [PATCH 2/5] Add uli1575 pci-bridge sector to=20
> MPC8641HPCN dts file.
>=20
> where is the new uli1575 node referred except for this added snippet?
> thanks,
> xianghua

There're no other places now. You means the 'uli1757:' must be removed?

Thanks!
Wei

>=20
> Zhang Wei wrote:
>=20
> >Add uli1575 pci-bridge sector. It fixes the issue of ULI1575=20
> not found on rev.2 board.
> >
> >Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> >---
> > arch/powerpc/boot/dts/mpc8641_hpcn.dts      |    6 ++++++
> > arch/powerpc/boot/dts/mpc8641_hpcn_srio.dts |    6 ++++++
> > 2 files changed, 12 insertions(+), 0 deletions(-)
> >
> >diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts=20
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> >index 260b264..04626b1 100644
> >--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> >+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> >@@ -297,6 +297,12 @@
> > 				interrupts =3D <49 2>;
> > 				interrupt-parent =3D <&mpic>;
> > 			};
> >+			uli1575: uli1575@100 {
> >+				reg =3D <0 0 0 0 0>;
> >+				pci_bridge@200 {
> >+					reg =3D <0 0 0 0 0>;
> >+				};
> >+			};
> >=20
> > 		};
> >=20
> > =20
> >
>=20
>=20

Re: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Jon Loeliger]

On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Add uli1575 pci-bridge sector. It fixes the issue of ULI1575 not found on rev.2 board.
> 
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>

Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>

Re: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Kumar Gala]

On May 21, 2007, at 10:38 PM, Zhang Wei wrote:

> Add uli1575 pci-bridge sector. It fixes the issue of ULI1575 not  
> found on rev.2 board.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
>  arch/powerpc/boot/dts/mpc8641_hpcn.dts      |    6 ++++++
>  arch/powerpc/boot/dts/mpc8641_hpcn_srio.dts |    6 ++++++
>  2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/ 
> boot/dts/mpc8641_hpcn.dts
> index 260b264..04626b1 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -297,6 +297,12 @@
>  				interrupts = <49 2>;
>  				interrupt-parent = <&mpic>;
>  			};
> +			uli1575: uli1575@100 {

is this the right address?

> +				reg = <0 0 0 0 0>;
> +				pci_bridge@200 {
> +					reg = <0 0 0 0 0>;
> +				};
> +			};
>
>  		};

Can someone look at merging this with Wade's patch to add the ISA  
devices

- k

RE: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Zhang Wei-r63237]

Hi,=20

> > +			uli1575: uli1575@100 {
>=20
> is this the right address?

'@100' of here, I make up  the address by get from bus 1, device 0,
function 0.
Such as below '@200' means bus 2, device 0, function0.

Re: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Segher Boessenkool]

>>> +			uli1575: uli1575@100 {
>>
>> is this the right address?
>
> '@100' of here, I make up  the address by get from bus 1, device 0,
> function 0.
> Such as below '@200' means bus 2, device 0, function0.

That is not how PCI unit addresses are encoded.  There are
two forms: bla@D and bla@D,F where D and F are device# and
function# respectively.  The bus# is implicit from the
parent node.

You have the "reg" property wrong, too (but differently).


Segher

RE: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Benjamin Herrenschmidt]

On Wed, 2007-05-30 at 18:02 +0800, Zhang Wei-r63237 wrote:
> Hi, 
> 
> > > +			uli1575: uli1575@100 {
> > 
> > is this the right address?
> 
> '@100' of here, I make up  the address by get from bus 1, device 0,
> function 0.
> Such as below '@200' means bus 2, device 0, function0.

It's PCI ? The unit address is well defined then, check the PCI bindings
to OF

Ben.

Re: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

[Wade Farnsworth]

This adds device nodes for the PCI bridges as well as the ISA devices on
the newer revision MPC8641HPCN.  It also adds the PCI ranges to the soc
node so that address translation for the ISA devices works properly.

Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>

---
Here's the merged patch.

I've updated the ISA nodes somewhat according to the comments the
original patch received.

I also took the liberty of fixing the addresses of the pci bridges and
removing the unused "uli1575:" label.

 arch/powerpc/boot/dts/mpc8641_hpcn.dts |   89 +++++++++++++++++++----
 1 file changed, 77 insertions(+), 12 deletions(-)

Index: linux-2.6-powerpc-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
===================================================================
--- linux-2.6-powerpc-8641.orig/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ linux-2.6-powerpc-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -56,7 +56,11 @@
 		#size-cells = <1>;
 		#interrupt-cells = <2>;
 		device_type = "soc";
-		ranges = <0 f8000000 00100000>;
+		ranges = <00000000 f8000000 00100000
+			  80000000 80000000 20000000
+			  e2000000 e2000000 00100000
+			  a0000000 a0000000 20000000
+			  e3000000 e3000000 00100000>;
 		reg = <f8000000 00100000>;	// CCSRBAR 1M
 		bus-frequency = <0>;
 
@@ -285,17 +289,78 @@
 				f800 0 0 3 &i8259 0 0
 				f800 0 0 4 &i8259 0 0
 				>;
-			i8259: i8259@4d0 {
-				clock-frequency = <0>;
-				interrupt-controller;
-				device_type = "interrupt-controller";
-				#address-cells = <0>;
-				#interrupt-cells = <2>;
-				built-in;
-				compatible = "chrp,iic";
-                	        big-endian;
-				interrupts = <49 2>;
-				interrupt-parent = <&mpic>;
+			uli1575@0 {
+				reg = <0 0 0 0 0>;
+ 				#size-cells = <2>;
+ 				#address-cells = <3>;
+ 				ranges = <02000000 0 80000000
+ 					  02000000 0 80000000
+ 					  0 20000000
+ 					  01000000 0 00000000
+ 					  01000000 0 00000000
+ 					  0 00100000>;
+
+				pci_bridge@0 {
+					reg = <0 0 0 0 0>;
+ 					#size-cells = <2>;
+ 					#address-cells = <3>;
+ 					ranges = <02000000 0 80000000
+ 						  02000000 0 80000000
+ 						  0 20000000
+ 						  01000000 0 00000000
+ 						  01000000 0 00000000
+ 						  0 00100000>;
+
+ 					isa@1e {
+ 						device_type = "isa";
+ 						#interrupt-cells = <2>;
+ 						#size-cells = <1>;
+ 						#address-cells = <2>;
+ 						reg = <f000 0 0 0 0>;
+ 						ranges = <1 0 01000000 0 0
+ 							  00001000>;
+ 						interrupt-parent = <&i8259>;
+
+ 						i8042@60 {
+ 							reg = <1 60 1 1 64 1>;
+ 							interrupts = <1 3 c 3>;
+ 							interrupt-parent =
+ 								<&i8259>;
+
+ 							keyboard@0 {
+ 								compatible = "pnpPNP,303";
+ 	 						};
+
+ 							mouse@1 {
+ 								compatible = "pnpPNP,f03";
+ 							};
+ 						};
+
+ 						rtc@70 {
+ 							compatible =
+ 								"pnpPNP,b00";
+ 							reg = <1 70 2>;
+ 						};
+
+ 						gpio@400 {
+ 							reg = <1 400 80>;
+ 						};
+
+ 						i8259: i8259@4d0 {
+ 							clock-frequency = <0>;
+ 							interrupt-controller;
+ 							device_type = "interrupt-controller";
+ 							#address-cells = <0>;
+ 							#interrupt-cells = <2>;
+ 							built-in;
+ 							compatible = "chrp,iic";
+ 							big-endian;
+ 							interrupts = <49 2>;
+ 							interrupt-parent =
+ 								<&mpic>;
+ 						};
+					};
+				};
 			};
 
 		};

Re: [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.

[Jon Loeliger]

On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Remove the errata fix codes for MPC8641 silicon ver 1.0 which
> is end of life.
> 
> The MPC8641 silicon ver 1.0 is not fully support PCI/PCI Express
> specifications. The revision 2.0 fixes all of these errata
> and the rev 1.0 silicon is end of life. So errata codes are removed.
> 
> Now, The chip is full compatible with PCI/PCI Express
> specifications. The generic PCI code is used.
> 
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Acked-by: Roy Zang <tie-fei.zang@freescale.com>

Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>

Re: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[Kumar Gala]

On May 21, 2007, at 10:38 PM, Zhang Wei wrote:

> Hi, Paul,
>
> The below 5 patches add the support for MPC8641 rev 2.0 silicon and  
> MPC8641HPCN board 2.0.
>
>   [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver  
> 1.0 which is end of life.
>   [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
>   [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
>   [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer  
> legacy I/O access.
>   [PATCH 5/5] Set IDE in ULI1575 to not native mode.
>
> The MPC8641 rev 2.0 silicon fix the PCI/PCI-Express errata in rev  
> 1.0. And the rev 1.0 silicon is end of life. So the dts tree and  
> codes should be changes. Codes which are not compatible with PCI/ 
> PCI-Express specifications are removed. Some minor issues are fixed.

How do these patches differ/interace from what Wade posted a few days  
ago?

Also, please CC me on future Freescale related patches.

- k

RE: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[Zhang Wei-r63237]

Hi, Kumar,

Please see my inline comments:
> >
> >   [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver =20
> > 1.0 which is end of life.

This patch is not included in Wade's patch.

MPC8641 silicon 1.0 is end of life and not full following
PCI/PCI-Express specifications.
Rev 2.0 silicon fixes these PCI/PCI-Express errata and follows the
PCI/PCI-Ex specifications.
So, using generic PCI codes is okay.


> >   [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

This's a simple and clear solution to Wade's pci fix patch. Some changes
of Wade's pci fix patch are redundant.

> >   [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.

This patch is not included in Wade's patch.

Every PCI hose bus range number is started from 0 before. This patch
make the hose bus range number is started from previous hose last bus
number added one.
And PCI-Ex tranining status check is added to avoid the system halt.

> >   [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer =20
> > legacy I/O access.

This patch is different than Wade's pci fix patch.
Wade's pci patch changing MPC8641 PCI_CLASS property is not a good
solution. Only set it to transport bridge is okay.
And this quirk functions should applied to both MPC8641 and MPC8641D,
not only dual core version.

> >   [PATCH 5/5] Set IDE in ULI1575 to not native mode.

This patch is not included in Wade's patch.
It makes IDE in ULI1575 works.

>=20
> How do these patches differ/interace from what Wade posted a=20
> few days =20
> ago?

Wade's MTD patch (patch 1), Legacy patch (patch 2), superIO patch (patch
3), RTC patch (patch 4) is not overlap with my patches.
But Wade's PCI patch (patch 5) most of codes is for supporting a
discontinued and end of life silicon and I do not agree with the changes
about PCI_CLASS of MPC8641. The dts fixing is too complex. I suggest to
reject Wade's PCI patch.

Thanks!
Wei

Re: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[Kumar Gala]

On May 21, 2007, at 11:46 PM, Zhang Wei-r63237 wrote:

> Hi, Kumar,
>
> Please see my inline comments:
>>>
>>>   [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver
>>> 1.0 which is end of life.
>
> This patch is not included in Wade's patch.
>
> MPC8641 silicon 1.0 is end of life and not full following
> PCI/PCI-Express specifications.
> Rev 2.0 silicon fixes these PCI/PCI-Express errata and follows the
> PCI/PCI-Ex specifications.
> So, using generic PCI codes is okay.

Was rev1.0 silicon ever used by customers w/ production systems?

>>>   [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
>
> This's a simple and clear solution to Wade's pci fix patch. Some  
> changes
> of Wade's pci fix patch are redundant.
>
>>>   [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
>
> This patch is not included in Wade's patch.
>
> Every PCI hose bus range number is started from 0 before. This patch
> make the hose bus range number is started from previous hose last bus
> number added one.
> And PCI-Ex tranining status check is added to avoid the system halt.
>
>>>   [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer
>>> legacy I/O access.
>
> This patch is different than Wade's pci fix patch.
> Wade's pci patch changing MPC8641 PCI_CLASS property is not a good
> solution. Only set it to transport bridge is okay.
> And this quirk functions should applied to both MPC8641 and MPC8641D,
> not only dual core version.
>
>>>   [PATCH 5/5] Set IDE in ULI1575 to not native mode.
>
> This patch is not included in Wade's patch.
> It makes IDE in ULI1575 works.
>
>>
>> How do these patches differ/interace from what Wade posted a
>> few days
>> ago?
>
> Wade's MTD patch (patch 1), Legacy patch (patch 2), superIO patch  
> (patch
> 3), RTC patch (patch 4) is not overlap with my patches.
> But Wade's PCI patch (patch 5) most of codes is for supporting a
> discontinued and end of life silicon and I do not agree with the  
> changes
> about PCI_CLASS of MPC8641. The dts fixing is too complex. I  
> suggest to
> reject Wade's PCI patch.

Is Wade going to rebase his patches on top of your's?

- k

Re: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[Jon Loeliger]

On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Hi, Paul,
> 
> The below 5 patches add the support for MPC8641 rev 2.0 silicon and MPC8641HPCN board 2.0.
> 
>   [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.
>   [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
>   [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
>   [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
>   [PATCH 5/5] Set IDE in ULI1575 to not native mode.
> 
> The MPC8641 rev 2.0 silicon fix the PCI/PCI-Express errata in rev 1.0. And the rev 1.0 silicon is end of life. So the dts tree and codes should be changes. Codes which are not compatible with PCI/PCI-Express specifications are removed. Some minor issues are fixed.
> 
> Thanks!
> 
> Best Regards,
> Zhang Wei


Hi Guys,

Until I can get this to work in my test tree, I'd like
to delay these patches.  I'm neither NACK'ing nor ACK'ing
them at this point in time.

Thanks,
jdl

Re: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[Wade Farnsworth]

On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
> Hi, Paul,
> 
> The below 5 patches add the support for MPC8641 rev 2.0 silicon and MPC8641HPCN board 2.0.
> 
>   [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.
>   [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
>   [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
>   [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
>   [PATCH 5/5] Set IDE in ULI1575 to not native mode.
> 
> The MPC8641 rev 2.0 silicon fix the PCI/PCI-Express errata in rev 1.0. And the rev 1.0 silicon is end of life. So the dts tree and codes should be changes. Codes which are not compatible with PCI/PCI-Express specifications are removed. Some minor issues are fixed.
> 
> Thanks!
> 
> Best Regards,
> Zhang Wei
> 

I can't get your patches to apply to Paulus' tree.  Which tree are these
against?

--Wade

RE: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 andMPC8641HPCN board 2.0

[Zhang Wei-r63237]

Hi,

They are against to Paul's git tree and I've verified these patches
again today.

They can be applied to Paul's top git tree successfully.

Thanks!
Wei=20

> -----Original Message-----
> From: Wade Farnsworth [mailto:wfarnsworth@mvista.com]=20
> Sent: Wednesday, May 23, 2007 1:47 AM
> To: Zhang Wei-r63237
> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 0/5] Add the support for MPC8641 silicon=20
> rev 2.0 andMPC8641HPCN board 2.0
>=20
> On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
> > Hi, Paul,
> >=20
> > The below 5 patches add the support for MPC8641 rev 2.0=20
> silicon and MPC8641HPCN board 2.0.
> >=20
> >   [PATCH 1/5] Remove the errata fix codes for MPC8641=20
> silicon ver 1.0 which is end of life.
> >   [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
> >   [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
> >   [PATCH 4/5] Set RC of mpc8641 to transparent bridge for=20
> transfer legacy I/O access.
> >   [PATCH 5/5] Set IDE in ULI1575 to not native mode.
> >=20
> > The MPC8641 rev 2.0 silicon fix the PCI/PCI-Express errata=20
> in rev 1.0. And the rev 1.0 silicon is end of life. So the=20
> dts tree and codes should be changes. Codes which are not=20
> compatible with PCI/PCI-Express specifications are removed.=20
> Some minor issues are fixed.
> >=20
> > Thanks!
> >=20
> > Best Regards,
> > Zhang Wei
> >=20
>=20
> I can't get your patches to apply to Paulus' tree.  Which=20
> tree are these
> against?
>=20
> --Wade
>=20
>=20

RE: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 andMPC8641HPCN board 2.0

[Wade Farnsworth]

On Wed, 2007-05-23 at 10:48 +0800, Zhang Wei-r63237 wrote:
> Hi,
> 
> They are against to Paul's git tree and I've verified these patches
> again today.
> 
> They can be applied to Paul's top git tree successfully.
> 
> Thanks!
> Wei 
> 

You're right, they do apply.  My local copy must have been messed up
somehow.  Sorry for the noise.

--Wade

Re: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0

[Jon Loeliger]

On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Hi, Paul,
> 
> The below 5 patches add the support for MPC8641 rev 2.0 silicon and MPC8641HPCN board 2.0.
> 
>   [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.
>   [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
>   [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
>   [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
>   [PATCH 5/5] Set IDE in ULI1575 to not native mode.
> 
> The MPC8641 rev 2.0 silicon fix the PCI/PCI-Express errata in rev 1.0. And the rev 1.0 silicon is end of life. So the dts tree and codes should be changes. Codes which are not compatible with PCI/PCI-Express specifications are removed. Some minor issues are fixed.
> 
> Thanks!
> 
> Best Regards,
> Zhang Wei

Paul,

I had earlier requested a "Hold" on this series of patches
until I was able to see it work on my system too.

I have now been able to  get working code here, but it
required a follow up set of 3 patches that I wrote.

So:  I will ACK these 5 from Zhang Wei, and then post
my 3 more patches.  If you would, please pick these up!

Thanks,
jdl