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/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:32 EST