the tokens are legal ANSI-C. Maybe to enable 'op' to be a macro itself?
Anyway, with the ## concatenation Gcc 3.1's integrated `cpp' treats "=op("
as a single token vs. the three tokens it is.
the chipset. This is already how the multi-hose systems handle resource
allocation and it fixes a bug where dense and bwx memory allocations were
not handled properly.
Reviewed by: gallatin
- Move PCI core code to dev/pci.
- Split bridge code out into separate modules.
- Remove the descriptive strings from the bridge drivers. If you
want to know what a device is, use pciconf. Add support for
broadly identifying devices based on class/subclass, and for
parsing a preloaded device identification database so that if
you want to waste the memory, you can identify *anything* we know
about.
- Remove machine-dependant code from the core PCI code. APIC interrupt
mapping is performed by shadowing the intline register in machine-
dependant code.
- Bring interrupt routing support to the Alpha
(although many platforms don't yet support routing or mapping
interrupts entirely correctly). This resulted in spamming
<sys/bus.h> into more places than it really should have gone.
- Put sys/dev on the kernel/modules include path. This avoids
having to change *all* the pci*.h includes.
like the args to the config space accessors these functions replaced.
This reduces the likelyhood of overflow when the args are used in
macros on the alpha. This prevents memory management faults when
probing the pci bus on sables, multias and nonames.
Approved by: dfr
Tested by: Bernd Walter <ticso@cicely8.cicely.de>
foo_pcib_[read|write]_config() functions rather than relying on
a break or return being in the CFG macro.
This fixes a panic later in the boot process on a UP1000. From
inspection, it looks like this fixes a similar problem in the tsunami code.
Approved by: dfr
the drivers.
* Remove legacy inx/outx support from chipset and replace with macros
which call busspace.
* Rework pci config accesses to route through the pcib device instead of
calling a MD function directly.
With these changes it is possible to cleanly support machines which have
more than one independantly numbered PCI busses. As a bonus, the new
busspace implementation should be measurably faster than the old one.
chipsets. An example of this is the USB controller on these chipsets.
With this, I can now use USB devices on the test Alpha I am borrowing at
the moment.
Reviewed by: dfr, obrien
I was wagering on DEC being elegant & numbering PCI buses normally on
machines with one pchip. It looks like they went with consistent -- buses
behind ppbs begin with bus 2.
tsunami systems and the PCI bus-numbering system of FreeBSD. Eg, the former
allows for 2 PCI bus 2's (one each on hoses 0 and 1) while the latter
needs to give each PCI bus a unique monotonically increasing number.
It has been fairly well tested and correctly maps machines with a ppb on
hose 1 as well as machines with ppbs on both hoses.
DS10s remain untested, as I do not have a pci card with a ppb which will
pass POST in a tsunami.
This is a house of cards.
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
Rather than teaching pci_ioctl about hoses, we just pass down a magic number
& let the platform code figure out what the hose is based on what the bus
number is.
concept approved by dfr
Compaq XP1000, AlphaServer DS20, AlphaServer DS10, and DP264
This has been tested *only* on XP1000's. I'll be interested to hear from
owners of other types of DEC_ST6600 alphas.
I'd like to thank Don Rice of Compaq for providing the documentation required
to support this platform on FreeBSD. I'd also like to thank Doug Rabson for newbus,
and for helping me get a multiple hoses working with newbus.
Reviewed by: Doug Rabson <dfr@nlsystems.com>
