Messages in this thread | | | Date | Mon, 23 Dec 2002 18:26:24 +0300 | From | Ivan Kokshaysky <> | Subject | Re: PATCH 2.5.x disable BAR when sizing |
| |
On Mon, Dec 23, 2002 at 11:29:15AM +1100, Paul Mackerras wrote: > We could relocate the ASIC if we could find the ioremaps and fix them > up, or if we could get to all the drivers and have them re-do their > ioremaps. There is no way to do that at the moment, though. > Typically the ASIC will have a couple of IDE interfaces, audio, > serial, i2c, interrupt controller, wireless ethernet, timer, and PMU > (power management unit) interfaces in it, so there are several drivers > involved.
I see, thanks. I always had an impression that pci_init is called way too late in the boot sequence, at least on the PCI-centric systems. This makes all that PCI surgery really painful. Ideally, the init order should be defined per architecture. This applies to the generic device model as well: currently we have legacy, isa-pnp and other stuff initialized and probed *before* PCI, though typically these are hanging of the PCI bus. And it's a real problem on machines with multiple PCI buses. Oh, well...
> In fact we don't really need to probe the BARs of the ASIC at all, > because the device tree that we get from Open Firmware tells us the > size and location of the resources it is using (along with all the > other PCI devices in the system). If we could have a > platform-specific hook so that we could provide an alternative method > for probing the BARs of certain PCI devices, that would let us avoid > the whole problem.
It can be trivially done using Linus' idea of probing in 2 phases. The pass 1 can be made 100% non-destructive: we can initialize device structures, read in device/vendor IDs, class codes and build the bus trees. Basically, everything that we do currently minus pci_read_bases(), so the resource fields are blank. Then we can call arch- and device-specific routines, where along with other fixups the device BARs could be probed in arch-specific way and written down in the pci_dev structure. In the pass 2 (generic BAR probing), we can check the resource flags for non-zero value and skip the probe of respective BAR. This would make the code a LOT more flexible.
Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |