On Mon, Mar 22, 2010 at 04:11:33PM -0700, Bjorn Helgaas wrote: > > (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? Well, PCI devices have three advantages: - they can more easily be "enumerated" (and their resource needs reflected) by ACPI or the BIOS. - they usually don't conflict with ISA-style hardware(?) - they usually work happily with any (even high) I/O ports. > > => 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? No, that's excactly what I'm seeing here. On pre-2008 system, the behavior is still the same; no unexpected change; all fine unless I boot with "pci=use_crs". In contrast, on post-2008 systems like Komuros system, we now trust to ACPI report _all_ resource users. If ACPI gets this right, I don't see a real problem (but I might add a safety check to avoid any I/O ports < 0x0100 anyway). The remaining question: can we safely trust BIOS authors to get it right? Dominik -- 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
