PATCH: Fix CardBus bridge behind a PCI bridge

PATCH: Fix CardBus bridge behind a PCI bridge

Post by H. J. L » Wed, 14 Aug 2002 03:00:04







> > > > There's a current thread on linux-kernel about "PCI hotplug resource
> > > > reservation" that is relevant, and there's a patch that claims to
> > > > provide a workable solution to the problem for cPCI.

> > > Thanks. Do you think if the "PCI<->PCI bridges, transparent resource
> > > fix" thread is related to it?

> > I glanced at that and didn't think so, but I didn't read much.

> I think they are relevant. Your pcmcia-cs 3.20 works fine on Sony. Here
> is the output of "lspci -v". PCI bride has

>    I/O behind bridge: 00004000-00004fff
>    Memory behind bridge: e8200000-e82fffff

> The kernel cardbus code tries to allocate memory and I/O from them. It
> doesn't work. BTW, I checked another notebook. That code is not reached
> at all since slot has been initialized by BIOS. Your pcmcia-cs doesn't
> follow the PCI brigde:

>    I/O ports at 0200
>    Memory at 60040000 (32-bit, non-prefetchable)

> and works. Any ides why?

Here is a patch against 2.4.18 to fix CardBus bridge behind a PCI
bridge with positive decode. I checked Windows XP. It is how it
allocates resources for the CardBus slots, that is outside of
the memory and I/O windows on the PCI bridge.

Let me know if it works for you.

H.J.

  linux-2.4.18-yenta-bridge.patch
1K Download
 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by H. J. L » Wed, 14 Aug 2002 06:10:09




> > > what does "positive decode" mean in this context?  Does the bridge
> > > somehow figure out that if no other device claims a transaction, that
> > > it should do so?

> > I am not a PCI expert. As I understand, if a PCI bridge does negative
> > decode, you don't need to do it for the CardBus bride behind it. I
> > guess it is only needed for positive decode. For some reason, a PCI
> > bridge with positive decode may pass address to the CardBus bridge
> > behind it or the CardBus bridge has some back door to the PCI bus.

> I pulled up the datasheet for this chip and now I think maybe I
> understand what's going on.

> It says that the PCI-to-PCI bridge function in this chip forwards all
> transactions to the external PCI bus.  The bridge windows determine
> ranges of addresses which it may claim back as a target, in this case
> I guess just for the LAN function, which is the only integrated device
> on bus 2.

> So this actually seems to be effectively a transparent bridge.

How about this pacth? It works for me.

H.J.

  linux-2.4.18-yenta-bridge.patch
1K Download

 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by H. J. L » Wed, 14 Aug 2002 12:40:04



> I guess the advantage of your original patch is that I think it should
> never hurt, and will help in any situation where a PCI bridge actually
> is transparent.

I was told all PCI_CLASS_BRIDGE_PCI bridges were transparent. The non-
transparent ones have class code PCI_CLASS_BRIDGE_OTHER. This new patch
only checks PCI_CLASS_BRIDGE_PCI and works for me.

H.J.

  linux-2.4.18-yenta-bridge.patch
1K Download
 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by Ivan Kokshaysk » Sun, 18 Aug 2002 01:00:05



> I was told all PCI_CLASS_BRIDGE_PCI bridges were transparent. The non-
> transparent ones have class code PCI_CLASS_BRIDGE_OTHER. This new patch
> only checks PCI_CLASS_BRIDGE_PCI and works for me.

I guess that info came from Intel ;-)  Interesting, but completely wrong.
The devices they call "non-transparent PCI-to-PCI bridges" aren't classic
PCI-to-PCI bridges at all, that's why they are PCI_CLASS_BRIDGE_OTHER.
It's more to do with CPU-to-CPU bridges.
In our terms, "transparent" PCI-to-PCI bridge means subtractive decoding one.
Your previous patch makes much more sense, although a) it should belong to
generic pci code b) is way incomplete.

Please try this one instead.

Ivan.

--- 2.4.19/drivers/pci/quirks.c Sat Aug  3 04:39:44 2002

        r -> end = 0xffffff;
 }

+static void __init quirk_transparent_bridge(struct pci_dev *dev)
+{
+       dev->class |= 1;
+}
+
 /*
  *  The main table of quirks.

        { PCI_FIXUP_FINAL,      PCI_VENDOR_ID_AMD,      PCI_DEVICE_ID_AMD_VIPER_7410,   quirk_amd_ioapic },
        { PCI_FIXUP_FINAL,      PCI_VENDOR_ID_AMD,      PCI_DEVICE_ID_AMD_FE_GATE_700C, quirk_amd_ordering },
+       /*
+        * i82380FB mobile docking controller: its PCI-to-PCI bridge
+        * is subtractive decoding (transparent), and does indicate this
+        * in the ProgIf. Unfortunately, in the wrong bit - 7 instead of 0.
+        */
+       { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82380FB,    quirk_transparent_bridge },

        { 0 }
 };
--- 2.4.19/drivers/pci/pci.c    Fri Aug 16 17:05:12 2002

        if (!dev)               /* It's a host bus, nothing to read */
                return;

+       if (dev->class & 1) {
+               printk("Transparent bridge - %s\n", dev->name);
+               for(i=0; i < 3; i++)
+                       child->resource[i] = child->parent->resource[i];
+               return;
+       }
+
        for(i=0; i<3; i++)
                child->resource[i] = &dev->resource[PCI_BRIDGE_RESOURCES+i];

                res->start = base;
                res->end = limit + 0xfff;
                res->name = child->name;
-       } else {
-               /*
-                * Ugh. We don't know enough about this bridge. Just assume
-                * that it's entirely transparent.
-                */
-               printk(KERN_ERR "Unknown bridge resource %d: assuming transparent\n", 0);
-               child->resource[0] = child->parent->resource[0];
        }


                res->start = base;
                res->end = limit + 0xfffff;
                res->name = child->name;
-       } else {
-               /* See comment above. Same thing */
-               printk(KERN_ERR "Unknown bridge resource %d: assuming transparent\n", 1);
-               child->resource[1] = child->parent->resource[1];
        }


                res->start = base;
                res->end = limit + 0xfffff;
                res->name = child->name;
-       } else {
-               /* See comments above */
-               printk(KERN_ERR "Unknown bridge resource %d: assuming transparent\n", 2);
-               child->resource[2] = child->parent->resource[2];
        }
 }

--- 2.4.19/arch/i386/kernel/pci-pc.c    Sat Aug  3 04:39:42 2002

        }
 }

+/*
+ * For some weird reasons Intel decided that certain parts of their
+ * 815, 845 and some other chipsets must look like PCI-to-PCI bridges
+ * while they are obviously not. The 82801xx (AA, AB, BAM/CAM, BA/CA/DB
+ * and E) PCI bridges are actually HUB-to-PCI ones, according to Intel
+ * terminology. These devices do forward all addresses from system to
+ * PCI bus no matter what are their window settings, so they are
+ * "transparent" (or subtractive decoding) from programmers point of view.
+ * Indicate this in ProgIf bit 0.
+ */
+static void __init pci_fixup_transparent_bridge(struct pci_dev *dev)
+{
+       if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
+           (dev->device & 0xff00) == 0x2400);
+               dev->class |= 1;
+}
+
 struct pci_fixup pcibios_fixups[] = {
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82451NX,    pci_fixup_i450nx },

        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_8361,         pci_fixup_via_northbridge_bug },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_8367_0,       pci_fixup_via_northbridge_bug },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_NCR,      PCI_DEVICE_ID_NCR_53C810,       pci_fixup_ncr53c810 },
+       { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_ANY_ID,                     pci_fixup_transparent_bridge },
        { 0 }
 };

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by H. J. L » Sun, 18 Aug 2002 15:00:05




> > I was told all PCI_CLASS_BRIDGE_PCI bridges were transparent. The non-
> > transparent ones have class code PCI_CLASS_BRIDGE_OTHER. This new patch
> > only checks PCI_CLASS_BRIDGE_PCI and works for me.

> I guess that info came from Intel ;-)  Interesting, but completely wrong.
> The devices they call "non-transparent PCI-to-PCI bridges" aren't classic
> PCI-to-PCI bridges at all, that's why they are PCI_CLASS_BRIDGE_OTHER.
> It's more to do with CPU-to-CPU bridges.
> In our terms, "transparent" PCI-to-PCI bridge means subtractive decoding one.
> Your previous patch makes much more sense, although a) it should belong to
> generic pci code b) is way incomplete.

> Please try this one instead.

CardBus works now. But I can no longer load usb-uhci. My X server no
longer works. Your patch is not right.

H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by Jeff Garzi » Mon, 19 Aug 2002 00:30:09





>>>I was told all PCI_CLASS_BRIDGE_PCI bridges were transparent. The non-
>>>transparent ones have class code PCI_CLASS_BRIDGE_OTHER. This new patch
>>>only checks PCI_CLASS_BRIDGE_PCI and works for me.

>>I guess that info came from Intel ;-)  Interesting, but completely wrong.
>>The devices they call "non-transparent PCI-to-PCI bridges" aren't classic
>>PCI-to-PCI bridges at all, that's why they are PCI_CLASS_BRIDGE_OTHER.
>>It's more to do with CPU-to-CPU bridges.
>>In our terms, "transparent" PCI-to-PCI bridge means subtractive decoding one.
>>Your previous patch makes much more sense, although a) it should belong to
>>generic pci code b) is way incomplete.

>>Please try this one instead.

> CardBus works now. But I can no longer load usb-uhci. My X server no
> longer works. Your patch is not right.

I would be willing to bet there is some silliness in the X server, at
least.  It's PCI code has always left a lot to be desired...

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by H. J. L » Mon, 19 Aug 2002 00:40:06






> >>>I was told all PCI_CLASS_BRIDGE_PCI bridges were transparent. The non-
> >>>transparent ones have class code PCI_CLASS_BRIDGE_OTHER. This new patch
> >>>only checks PCI_CLASS_BRIDGE_PCI and works for me.

> >>I guess that info came from Intel ;-)  Interesting, but completely wrong.
> >>The devices they call "non-transparent PCI-to-PCI bridges" aren't classic
> >>PCI-to-PCI bridges at all, that's why they are PCI_CLASS_BRIDGE_OTHER.
> >>It's more to do with CPU-to-CPU bridges.
> >>In our terms, "transparent" PCI-to-PCI bridge means subtractive decoding one.
> >>Your previous patch makes much more sense, although a) it should belong to
> >>generic pci code b) is way incomplete.

> >>Please try this one instead.

> > CardBus works now. But I can no longer load usb-uhci. My X server no
> > longer works. Your patch is not right.

> I would be willing to bet there is some silliness in the X server, at
> least.  It's PCI code has always left a lot to be desired...

It could be. But I doubt it. At least, I don't think you can treat a
AGP bridge like a 82801BAM/CAM bridge. I think 82801BAM/CAM is a
special case. You really have to read the datasheet to know for sure.

H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by Ivan Kokshaysk » Mon, 19 Aug 2002 19:40:05



> CardBus works now. But I can no longer load usb-uhci. My X server no
> longer works. Your patch is not right.

More info, please (probably off-list). Kernel and X error messages, and
'lspci -vvxxx' output from your machine.
Those "transparent" bridges cause too much problems, and I'm just trying
to find a generic solution...

Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by Ivan Kokshaysk » Mon, 19 Aug 2002 20:00:05



> It could be. But I doubt it. At least, I don't think you can treat a
> AGP bridge like a 82801BAM/CAM bridge. I think 82801BAM/CAM is a
> special case. You really have to read the datasheet to know for sure.

You're right by all means. AGP bridges are _always_ positive decoders.
The problems you've seen were caused by the wrong semicolon somehow
sneaked into the patch:

+static void __init pci_fixup_transparent_bridge(struct pci_dev *dev)
+{
+       if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
+           (dev->device & 0xff00) == 0x2400);
                                             ^ Ugh..
+               dev->class |= 1;
+}

Which means that I'm setting bit 0 in the ProgIf for _all_ Intel devices...
I'm really sorry about that.
Thanks for the pci dump - it's very useful anyway.

Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

PATCH: Fix CardBus bridge behind a PCI bridge

Post by H. J. L » Mon, 19 Aug 2002 23:30:09




> > It could be. But I doubt it. At least, I don't think you can treat a
> > AGP bridge like a 82801BAM/CAM bridge. I think 82801BAM/CAM is a
> > special case. You really have to read the datasheet to know for sure.

> You're right by all means. AGP bridges are _always_ positive decoders.
> The problems you've seen were caused by the wrong semicolon somehow
> sneaked into the patch:

> +static void __init pci_fixup_transparent_bridge(struct pci_dev *dev)
> +{
> +  if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
> +      (dev->device & 0xff00) == 0x2400);
>                                         ^ Ugh..
> +          dev->class |= 1;
> +}

> Which means that I'm setting bit 0 in the ProgIf for _all_ Intel devices...
> I'm really sorry about that.

Yes. It works now. Thanks.

H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Configuring PCI<-->PCI bridges behind Cardbus bridges

Can you offer me some help?
I have been asked to write a linux driver for a box
that contains two PCI slots.
The PCI bus topology looks like

  PCIBus (an arbitrary bus south of the host bus)
    ^
    |
    v
  PCI<-->Cardbus Bridge (offers 1/2 pcmcia slots)
    ^
    |
    v
  PCI<-->PCI Bridge (contained inside a cardbus card)
    ^
    |
    v
  PCI<-->PCI Bridge
    ^
    |
    v
  ----PCIBus---------
      ^    ^
      |    |
      v    v
   slot0  slot1

I have read and stepped through the PCI code in the kernel
trying to figure out how to:
a) configure the bus numbers of the 3 bridges (cardbus, and
   the two PCI bridges)
b) configure the Base address registers of the devices in
   slot0 and slot1
c) configure the memory windows of the three bridges

My understanding at the moment is that the BIOS configures
these devices at power-on reset and the kernel reads the
config registers and allocates resources etc. Nowhere have
I seen the kernel code write to the bus registers, the base
address registers or to the bridge window registers.

I have managed (in a very hacky way) to configure the
primary, secondary and subordinate bus numbers of the
bridges inside a kernel module.

Prior to hacking the memory space windows of the bridges
I was getting segmentation faults (obviously my read/write
operations were not making it through the bridges).
The bridge memory space windows I managed to configure (I
don't know if I got them right or not though) using
setpci -s bus:device.func .....
But when I perform reads and writes to the device, inserted in
one of the slots, I get all f's (0xffffffff) for every
location.

Admittedly I have not written a Cardbus compliant driver yet.
I am initially just trying to get one of our PCI cards working
in one of the slots in the above topology in anyway possible.

Can you offer me some help/direction on how best to:
a) scan for buses, bridges and devices behind a cardbus
   device/bridge
b) allocate kernel resources for the same
c) configure the bus register, base address registers and
   bridge windows

I was hoping to find functions within the kernel that
would do these for me but after a number of weeks I cannot
say for sure exactly what should be done.

Any assistance, help and direction would be greatly
appreciated.

Regards,
Cathal Curtis.

2. automount wildcards filling up messages log file

3. 2.4.21-rc6-ac1 PCMCIA: Cardbus bridge behind transparent P2P bridge

4. KSpread 1.1.1: How to link cells between tables/sheets of two kspread documents?

5. PCI-2-Cardbus bridge, Kernel PCMCIA services and Cardbus

6. Playing BIG .avi's off the CDROM with xanim

7. CardBus, PCI: Strange I/O ports assigned to CardBus bridge

8. AMD K6 233mhz

9. S1692DL Tiger 2 unknown PCI bridge :unknown Host bridge :unknown PCI Device

10. 32 bit Cardbus / PCI bridge

11. support for PCI CardBus bridge O2Micro OZ6832

12. 32 bit Cardbus / PCI bridge

13. transparent pci-pci bridges fix