On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:There is nothing wrong with it; please realize that mmconf and conf1 are just different cpu-side interfaces. Both produce precisely the *same* bus cycles as far as the lower 256-byte space is concerned. MMCONFIG for *some* of the devices? This doesn't sound realistic from technical point of view. MMCONFIG-only systems? Sure. I really hope to see these. But it won't be PC-AT architecture anymore. It has to be something like alpha, for instance, fully utilizing the 64-bit address space, and we'll have to have the whole low-level PCI infrastructure completely different for these future platforms anyway. Right now, each and every x86 chipset *does* require working conf1 just in order to set up the mmconf aperture. It's the very fundamental thing, sort of design philosophy. Ivan. --
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Kok, Auke | Re: Linux 2.6.21-rc1 |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Jeff Garzik | Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Eric Dumazet | [PATCH] net: remove superfluous call to synchronize_net() |
