On Monday 22 March 2010 04:52:35 pm Dominik Brodowski wrote: > Hey, > > On Mon, Mar 22, 2010 at 03:28:55PM -0700, Bjorn Helgaas wrote: > > On Monday 22 March 2010 02:51:21 pm Dominik Brodowski wrote: > > > On Mon, Mar 22, 2010 at 01:36:03PM -0700, Bjorn Helgaas wrote: > > > > > You can still use subtractive-decoded resources, but then you have to add > > > > > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo the > > > > > resource to a sysfs file). > > > > > > > > It's too bad we still have such manual configuration. > > > > > > Agreed. > > > > > > > Is there still > > > > information there that we can't figure out automatically? > > > > > > That's unknown to me -- are there any ISA-capable systems being sold? If so, > > > then I suspect the answer may be "yes". > > > > > > > > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ that all > > > > > resource "consumers" are accounted for. So the problem might be mitigated. > > > > > However, I wouldn't dare to use ioports 0x0-0xff anyways for they usually > > > > > are used for onboard legacy devices... > > > > > > > > Right. But PCMCIA is at no greater risk than regular PCI, right? > > > > It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000). > > > > > > No, PCMCIA will happily allocate below this limit. > > > > I saw "#define PCIBIOS_MIN_CARDBUS_IO PCIBIOS_MIN_IO" in yenta_socket.c > > and assumed it would take care of this, but I didn't look any deeper. > > > > I'm still confused about why PCMCIA is "special" in this regard and > > why pci=use_crs breaks it. Can you make up an example that illustrates > > the problem? > > Consider the following case: Thanks! Sorry to be so dense here ... > (1) The root PCI bus has _CRS I/O 0000-0cf7; 0d00-ffff "produced"; > > the (transparent) PCI-PCI bridge offers, as bus resources, to > downstream users 0x4000-0x4fff plus everything else because of > subtractive decoding; > > there is a yenta-style PCI-CardBus/PCMCIA bridge below this > PCI-PCI bridge. > > (2) There are some I/O ports which react rather unfriendly to being read or > written. Let's assume they're at 0x100-0x10f; and let's also assume that > the BIOS writers forgot to mention them at all in the ACPI _CRS > settings; no other part of the kernel knows about it. > > 0000-0cf7 : PCI Bus 0000:00 > ... > 00f0-00ff : fpu > 0170-0177 : 0000:00:1f.2 > > > (3) A PCMCIA card is inserted. It needs an I/O port resource of size 8. The > PCMCIA subsystem looks in its own resource database which I/O ports it > may use; there, it finds not only 0x4000-0x4fff but (with a small > exception) 0x0000-0xffff; as 0x0000-0x00ff are already assigned, it > happily assigns the first free area -- 0x100-0x108 -- to the PCMCIA > card. > > 0000-0cf7 : PCI Bus 0000:00 > ... > 00f0-00ff : fpu > 0100-0108 : pcmcia0.0 > 0170-0177 : 0000:00:1f.2 > > (4) The PCMCIA card and the PCMCIA driver are set up to work with an IO > resource at 0x100-0x108. As soon as they attempt to use this resource, > bad things happen (lockups, etc.) because of the reasons spelled out at > (2). We'd have exactly the same situation if we assigned I/O port 0x100 to a PCI device. Why can't we use the same strategy PCI uses to avoid it? > => It is only an issue if the ACPI resource descriptions are incomplete. It > is worse for PCMCIA because it happily assigns resources below 0x1000, where > such system/platform devices usually listen to. And usecrs worsens the > situation also in another regard: on my own laptop (a pre-2008 model), > pci=use_crs makes the PCI-PCI bridge to be marked as "transparent", while > pci=nocrs means the PCI-PCI bridge is assumed to be "non-transparent". Sorry to be slow again... The pci=use_crs and pci=nocrs options only affect the PCI host bridge; they don't affect PCI-PCI bridges at all, except that they change the set of resources available for subtractive- decode PCI-PCI bridges to forward. (Strictly speaking, they don't affect the *behavior* of the PCI-PCI bridges, they only affect our *idea* of what they're doing.) I'm thinking of the code in pci_setup_device() where we set dev->transparent based on the bridge's class code. Obviously, you must be thinking of something else. My intention was that on pre-2008 systems like your laptop, my patches would not change any behavior at all, unless you boot with "pci=use_crs". Are you seeing an unexpected change on your system? Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
