On 01/26/2010 10:17 AM, Jesse Barnes wrote: > On Tue, 26 Jan 2010 19:02:13 +0100 > "Rafael J. Wysocki" <rjw@xxxxxxx> wrote: >>> I'm quite concerned about this for .33 because I don't think Jeff's >>> configuration (Dell desktop with Intel x58 and large graphics device) >>> is unusual. >>> >>> The benefit of intel_bus.c is on machines with multiple IOHs, where we >>> need to figure out which address ranges go to which IOHs so we can >>> program downstream devices correctly. But even there, _CRS should give >>> us the information we need, so "pci=use_crs" should make these machines >>> work. >>> >>> I think we should remove intel_bus.c before .33. It's breaking boxes >>> and we don't know how to fix it. Even if we do find out how to fix it, >>> I think we should move toward using _CRS instead, because that's what >>> Windows uses and it's an easy way for the firmware to tell us about >>> platform quirks. >> >> Perhaps it would be sufficient to make pci=use_crs the default and leave the >> option to use intel_bus.c for whoever needs that? > > We can't make use_crs the default w/o some more _CRS handling fixes > (some firmwares have large lists we need to handle). > > We can disable intel_bus.c though. Yinghai, I'm inclined against the > intel_bus.c approach at this point. It seems unlikely we'll ever keep > it up to date with new bridges, since its approach differs so much from > how things are done in the Windows world, where the firmware provides > a list of resources. We'll always be playing catch up, and will > probably be behind the firmware most of the time since the docs with > the necessary info likely won't be public most of the time. > > For 2.6.33 I'd like a minimal fix though, can you disable it for all > but the multi-IOH case perhaps? ok, we have one patch to enable that only with multi-IOH case. YH -- 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
