[PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[Pavel Roskin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1114 bytes --]

Hello!

I'm using Blue&While G3.  I installed a CardBus bridge into a PCI slot.
The bridge uses TI PCI1410 chip.  16-bit PCMCIA cards work fine, but
CardBus cards don't work.  They are not shown by lspci.  I'm running
Debian unstable with Linux 2.6.6-bk9.

It turns out the PCI bridge (DEC 21154) only handles bus 1 and doesn't
forward requests to higher buses.  The CardBus card is configured to act
as a bridge from bus 1 to buses 2-5.  That's why requests to bus 2 don't
go through.

If I reconfigure the PCI bridge to handle buses 1-255, the CardBus cards
start working.  The attached patch add a fixup for DEC 21154 bridge.

If there are a better way to fix the problem with CardBus, I'm ready to
test other patches.

More information about the system (including kernel log) is available at
http://www.red-bean.com/~proski/g3bw/

As a side not, the kernel says that the Host bridge (Motorola MPC106
Grackle) is configured to support buses 0 and 1.  Those values come from
the "bus-range" property.  I believe this limitation is not enforced, or
it would also hinder CardBus support.

--
Regards,
Pavel Roskin

[-- Attachment #2: Type: TEXT/plain, Size: 1416 bytes --]

--- linux.orig/arch/ppc/kernel/pci.c
+++ linux/arch/ppc/kernel/pci.c
@@ -49,6 +49,7 @@ static void fixup_cpc710_pci64(struct pc
 extern void pmac_pci_fixup_cardbus(struct pci_dev* dev);
 extern void pmac_pci_fixup_pciata(struct pci_dev* dev);
 extern void pmac_pci_fixup_k2_sata(struct pci_dev* dev);
+extern void pmac_pci_fixup_dec_bridge(struct pci_dev* dev);
 #endif
 #ifdef CONFIG_PPC_OF
 static u8* pci_to_OF_bus_map;
@@ -72,6 +73,7 @@ struct pci_fixup pcibios_fixups[] = {
 #ifdef CONFIG_PPC_PMAC
 	/* We should add per-machine fixup support in xxx_setup.c or xxx_pci.c */
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_TI,	PCI_ANY_ID,			pmac_pci_fixup_cardbus },
+	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_DEC,	PCI_DEVICE_ID_DEC_21154,	pmac_pci_fixup_dec_bridge },
 	{ PCI_FIXUP_FINAL,	PCI_ANY_ID,		PCI_ANY_ID,			pmac_pci_fixup_pciata },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_SERVERWORKS, 0x0240,			pmac_pci_fixup_k2_sata },
 #endif /* CONFIG_PPC_PMAC */
--- linux.orig/arch/ppc/platforms/pmac_pci.c
+++ linux/arch/ppc/platforms/pmac_pci.c
@@ -1034,6 +1034,13 @@ void pmac_pci_fixup_cardbus(struct pci_d
 	}
 }

+void fixup_dec_bridge(struct pci_dev* dev)
+{
+	/* By default this bridge only handles bus 1.  This fixup allows
+	 * access to higher busses, which is needed for CardBus support */
+	pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, 255);
+}
+
 void pmac_pci_fixup_pciata(struct pci_dev* dev)
 {
        u8 progif = 0;

Re: [PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[Benjamin Herrenschmidt]

On Mon, 2004-05-24 at 10:30, Pavel Roskin wrote:
> Hello!
>
> I'm using Blue&While G3.  I installed a CardBus bridge into a PCI slot.
> The bridge uses TI PCI1410 chip.  16-bit PCMCIA cards work fine, but
> CardBus cards don't work.  They are not shown by lspci.  I'm running
> Debian unstable with Linux 2.6.6-bk9.
>
> It turns out the PCI bridge (DEC 21154) only handles bus 1 and doesn't
> forward requests to higher buses.  The CardBus card is configured to act
> as a bridge from bus 1 to buses 2-5.  That's why requests to bus 2 don't
> go through.
>
> If I reconfigure the PCI bridge to handle buses 1-255, the CardBus cards
> start working.  The attached patch add a fixup for DEC 21154 bridge.
>
> If there are a better way to fix the problem with CardBus, I'm ready to
> test other patches.
>
> More information about the system (including kernel log) is available at
> http://www.red-bean.com/~proski/g3bw/
>
> As a side not, the kernel says that the Host bridge (Motorola MPC106
> Grackle) is configured to support buses 0 and 1.  Those values come from
> the "bus-range" property.  I believe this limitation is not enforced, or
> it would also hinder CardBus support.

It's a bit nasty right now... You may bump into other problems, the
main issue is OF not setting a proper bus range.

Anyway, you should make your patch machine specific to avoid screwing
up other possible busses... (hrm... not too sure in fact if the linux
common PCI code will properly fixup the last subordinate bus number,
you may also want to only give a range of 5 or 10 bus numbers in case
somebody plugs another PCI card with a P2P bridge on it, maybe just
read the bus number and rewrite it adding 5 or so...)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[Pavel Roskin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2034 bytes --]

Hi, Benjamin!

On Mon, 24 May 2004, Benjamin Herrenschmidt wrote:

> > As a side not, the kernel says that the Host bridge (Motorola MPC106
> > Grackle) is configured to support buses 0 and 1.  Those values come from
> > the "bus-range" property.  I believe this limitation is not enforced, or
> > it would also hinder CardBus support.
>
> It's a bit nasty right now... You may bump into other problems, the
> main issue is OF not setting a proper bus range.

I actually tried to replace all references to "bus-range" with "bus-bogus"
in the kernel.  The kernel would print

Found Grackle (MPC106) PCI host bridge at 0x80000000. Firmware bus number: 0->255

instead of "0->1", but I didn't notice any difference with regards to
CardBus support.

> Anyway, you should make your patch machine specific to avoid screwing up
> other possible busses...

I have CONFIG_PPC_PMAC condition already.  This plus the exact vendor and
device ID should be machine specific.  I can check that the machine is
"PowerMac1,1" if you want.  I have no idea if G4 models have this problem.

> (hrm... not too sure in fact if the linux common PCI code will properly
> fixup the last subordinate bus number, you may also want to only give a
> range of 5 or 10 bus numbers in case somebody plugs another PCI card
> with a P2P bridge on it, maybe just read the bus number and rewrite it
> adding 5 or so...)

I assumed that all PCI devices inserted to the slots would be on the bus 1
and thus behind the DEC bridge I'm reconfiguring.

Now I see that the video card is on bus 0 somehow.  Maybe that particular
slot is wired differently.  If you really think that somebody could insert
a P2P bridge instead of the video card, then maybe I should leave some
space.  I seem to remember that some multihead cards (Colorgraphic
Predator LT) have internal bridges.

There are 3 PCI slots other than VGA.  Every card can have 2 CardBus
slots.  Every CardBus bridge uses 4 buses.  That's 24 buses, from 2 to 25.

The fixed patch is attached.

--
Regards,
Pavel Roskin

[-- Attachment #2: Type: TEXT/plain, Size: 1621 bytes --]

--- linux.orig/arch/ppc/kernel/pci.c
+++ linux/arch/ppc/kernel/pci.c
@@ -49,6 +49,7 @@ static void fixup_cpc710_pci64(struct pc
 extern void pmac_pci_fixup_cardbus(struct pci_dev* dev);
 extern void pmac_pci_fixup_pciata(struct pci_dev* dev);
 extern void pmac_pci_fixup_k2_sata(struct pci_dev* dev);
+extern void pmac_pci_fixup_dec_bridge(struct pci_dev* dev);
 #endif
 #ifdef CONFIG_PPC_OF
 static u8* pci_to_OF_bus_map;
@@ -72,6 +73,7 @@ struct pci_fixup pcibios_fixups[] = {
 #ifdef CONFIG_PPC_PMAC
 	/* We should add per-machine fixup support in xxx_setup.c or xxx_pci.c */
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_TI,	PCI_ANY_ID,			pmac_pci_fixup_cardbus },
+	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_DEC,	PCI_DEVICE_ID_DEC_21154,	pmac_pci_fixup_dec_bridge },
 	{ PCI_FIXUP_FINAL,	PCI_ANY_ID,		PCI_ANY_ID,			pmac_pci_fixup_pciata },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_SERVERWORKS, 0x0240,			pmac_pci_fixup_k2_sata },
 #endif /* CONFIG_PPC_PMAC */
--- linux.orig/arch/ppc/platforms/pmac_pci.c
+++ linux/arch/ppc/platforms/pmac_pci.c
@@ -1034,6 +1034,21 @@ void pmac_pci_fixup_cardbus(struct pci_d
 	}
 }

+/* By default the PCI bridge on Blue&White G3 only handles bus 1.   This
+ * fixup allows access to higher buses in case if PCI or Cardbus bridge
+ * is added to the system.  */
+void pmac_pci_fixup_dec_bridge(struct pci_dev* dev)
+{
+	u8 val;
+
+	if (!machine_is_compatible("PowerMac1,1"))
+		return;
+
+	if (pci_read_config_byte(dev, PCI_SUBORDINATE_BUS, &val) == 0 &&
+	    val < 25)
+		pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, 25);
+}
+
 void pmac_pci_fixup_pciata(struct pci_dev* dev)
 {
        u8 progif = 0;

Re: [PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[Benjamin Herrenschmidt]

On Mon, 2004-05-24 at 15:21, Pavel Roskin wrote:
> Hi, Benjamin!
>
> On Mon, 24 May 2004, Benjamin Herrenschmidt wrote:
>
> > > As a side not, the kernel says that the Host bridge (Motorola MPC106
> > > Grackle) is configured to support buses 0 and 1.  Those values come from
> > > the "bus-range" property.  I believe this limitation is not enforced, or
> > > it would also hinder CardBus support.
> >
> > It's a bit nasty right now... You may bump into other problems, the
> > main issue is OF not setting a proper bus range.
>
> I actually tried to replace all references to "bus-range" with "bus-bogus"
> in the kernel.  The kernel would print
>
> Found Grackle (MPC106) PCI host bridge at 0x80000000. Firmware bus number: 0->255
>
> instead of "0->1", but I didn't notice any difference with regards to
> CardBus support.
>
> > Anyway, you should make your patch machine specific to avoid screwing up
> > other possible busses...
>
> I have CONFIG_PPC_PMAC condition already.  This plus the exact vendor and
> device ID should be machine specific.  I can check that the machine is
> "PowerMac1,1" if you want.  I have no idea if G4 models have this problem.
>
> > (hrm... not too sure in fact if the linux common PCI code will properly
> > fixup the last subordinate bus number, you may also want to only give a
> > range of 5 or 10 bus numbers in case somebody plugs another PCI card
> > with a P2P bridge on it, maybe just read the bus number and rewrite it
> > adding 5 or so...)
>
> I assumed that all PCI devices inserted to the slots would be on the bus 1
> and thus behind the DEC bridge I'm reconfiguring.

They can have P2P bridges too. For example, some adaptecs have a P2P
bridge and 2 controllers behind it. Some e1000 cards too.


> Now I see that the video card is on bus 0 somehow.  Maybe that particular
> slot is wired differently.  If you really think that somebody could insert
> a P2P bridge instead of the video card, then maybe I should leave some
> space.  I seem to remember that some multihead cards (Colorgraphic
> Predator LT) have internal bridges.
>
> There are 3 PCI slots other than VGA.  Every card can have 2 CardBus
> slots.  Every CardBus bridge uses 4 buses.  That's 24 buses, from 2 to 25.
>
> The fixed patch is attached.
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[Pavel Roskin]

On Mon, 24 May 2004, Benjamin Herrenschmidt wrote:

[snip]
> > > (hrm... not too sure in fact if the linux common PCI code will properly
> > > fixup the last subordinate bus number, you may also want to only give a
> > > range of 5 or 10 bus numbers in case somebody plugs another PCI card
> > > with a P2P bridge on it, maybe just read the bus number and rewrite it
> > > adding 5 or so...)
> >
> > I assumed that all PCI devices inserted to the slots would be on the bus 1
> > and thus behind the DEC bridge I'm reconfiguring.
>
> They can have P2P bridges too. For example, some adaptecs have a P2P
> bridge and 2 controllers behind it. Some e1000 cards too.

I guess we don't understand each other.  I thought you didn't like that I
the PCI bridge would handle all buses from 1 to 255.  I assumed that you
meant that some of those buses can be used by some other PCI bridges.  I
assumed that if the P2P bridge is behind the main PCI bridge, the buses
handled by the P2P bridge would be a subset of the buses handles by the
the main PCI bridge.

I assure you that every CardBus bridge would only use 4 buses.  It won't
use all 253 buses.

Anyway, you know PowerPC architecture much better.  I might be missing
something obvious.  After all, the upper bus range is just a number.
Adjust it in any direction if you want.

--
Regards,
Pavel Roskin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[Benjamin Herrenschmidt]

> I guess we don't understand each other.  I thought you didn't like that I
> the PCI bridge would handle all buses from 1 to 255.  I assumed that you
> meant that some of those buses can be used by some other PCI bridges.  I
> assumed that if the P2P bridge is behind the main PCI bridge, the buses
> handled by the P2P bridge would be a subset of the buses handles by the
> the main PCI bridge.

You are right, I was on crack

> I assure you that every CardBus bridge would only use 4 buses.  It won't
> use all 253 buses.
>
> Anyway, you know PowerPC architecture much better.  I might be missing
> something obvious.  After all, the upper bus range is just a number.
> Adjust it in any direction if you want.
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] Fixup for DEC 21154 bridge to allow CardBus support

[Pavel Roskin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 373 bytes --]

Hello!

The improved patch is attached.  The bridge is configured to handle buses
from 1 to 255.  Since both the PCI ID and the machine type are checked and
255 is the maximal value, it should be safe not to read the original value
of the upper limit.  The quirk has been renamed to
pmac_pci_fixup_bus_range(), which describes better what is does.

--
Regards,
Pavel Roskin

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1562 bytes --]

--- linux.orig/arch/ppc/kernel/pci.c
+++ linux/arch/ppc/kernel/pci.c
@@ -49,6 +49,7 @@ static void fixup_cpc710_pci64(struct pc
 extern void pmac_pci_fixup_cardbus(struct pci_dev* dev);
 extern void pmac_pci_fixup_pciata(struct pci_dev* dev);
 extern void pmac_pci_fixup_k2_sata(struct pci_dev* dev);
+extern void pmac_pci_fixup_bus_range(struct pci_dev* dev);
 #endif
 #ifdef CONFIG_PPC_OF
 static u8* pci_to_OF_bus_map;
@@ -72,6 +73,7 @@ struct pci_fixup pcibios_fixups[] = {
 #ifdef CONFIG_PPC_PMAC
 	/* We should add per-machine fixup support in xxx_setup.c or xxx_pci.c */
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_TI,	PCI_ANY_ID,			pmac_pci_fixup_cardbus },
+	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_DEC,	PCI_DEVICE_ID_DEC_21154,	pmac_pci_fixup_bus_range },
 	{ PCI_FIXUP_FINAL,	PCI_ANY_ID,		PCI_ANY_ID,			pmac_pci_fixup_pciata },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_SERVERWORKS, 0x0240,			pmac_pci_fixup_k2_sata },
 #endif /* CONFIG_PPC_PMAC */
--- linux.orig/arch/ppc/platforms/pmac_pci.c
+++ linux/arch/ppc/platforms/pmac_pci.c
@@ -1034,6 +1034,17 @@ void pmac_pci_fixup_cardbus(struct pci_d
 	}
 }
 
+/* By default the PCI bridge on Blue&White G3 only handles bus 1.   This
+ * fixup allows access to higher buses in case if PCI or Cardbus bridge
+ * is added to the system.  */
+void pmac_pci_fixup_bus_range(struct pci_dev* dev)
+{
+	if (!machine_is_compatible("PowerMac1,1"))
+		return;
+
+	pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, 255);
+}
+
 void pmac_pci_fixup_pciata(struct pci_dev* dev)
 {
        u8 progif = 0;