#if'ed out for a while. Complete the deed and tidy up some other bits.
We need to be able to call this stuff from outer edges of interrupt
handlers for devices that have the ISR bits in pci config space. Making
the bios code mpsafe was just too hairy. We had also stubbed it out some
time ago due to there simply being too much brokenness in too many systems.
This adds a leaf lock so that it is safe to use pci_read_config() and
pci_write_config() from interrupt handlers. We still will use pcibios
to do interrupt routing if there is no acpi.. [yes, I tested this]
Briefly glanced at by: imp
These are still unknown name but these are working as well
as the other ServerWorks chipset.
Description strings should be corrected when the chipsets
are known.
MFC after: 1 week
route interrupts if the child bus is described in the PCIBIOS interrupt
routing table. For child busses that are in the routing table, they do
not necessarily use a 'swizzle' on their pins on the parent bus to route
interrupts for child devices. If the child bus is an embedded device then
the pins on the child devices can be (and usually are) directly connected
either to a PIC or to a Interrupt Router. This fixes PCIBIOS interrupt
routing across PCI-PCI bridges for embedded devices.
IRQ for an entry in a PCIBIOS interrupt routing ($PIR) table.
- Change pci_cfgintr() to except the current IRQ of a device as a fourth
argument and to use that IRQ for the device if it is valid.
- If an intpin entry in a $PIR entry has a link of 0, it means that that
intpin isn't connected to anything that can trigger an interrupt. Thus,
test the link against 0 to find invalid entries in the table instead of
implicitly relying on the irqs field to be zero. In the machines I have
looked at, intpin entries with a link of 0 often have the bits for all
possible interrupts for PCI devices set.
identify this gadget on the CPUID result alone, so I intend to activate
the necessary magic (i8254 frequency for instance) for it based on the
precense of the on-chip host to PCI bridge.
some bios vendors took it apon themselves to "censor" the
host->pci bridges from PCIBIOS callers, even when the caller
explicitly asks for them. This includes certain Compaq machines
(eg: DL360) and some laptops.
If we detect this, shut down pcibios and revert to using IO
port bashing.
Under -current, apcica does a better job anyway.
- 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.
systems.
From the PR:
When 'probe.slot' is PCI_SLOTMAX (== 31) and 'probe.func' is 7,
call to 'pci_cfgread()' here and machine suddenly hangs up.
I don't know why... (or 450GX chipset's bug?)
PR: i386/20379
Submitted by: Masayuki FUKUI <fukui@sonic.nm.fujitsu.co.jp>
i386/isa/pcibus.c. This gets -current running again on multiple host->pci
machines after the most recent nexus commits. I had discussed this with
Mike Smith, but ended up doing it slightly differently to what we
discussed as it turned out cleaner this way. Mike was suggesting creating
a new resource (SYS_RES_PCIBUS) or something and using *_[gs]et_resource(),
but IMHO that wasn't ideal as SYS_RES_* is meant to be a global platform
property, not a quirk of a given implementation. This does use the ivar
methods but does so properly. It also now prints the physical pci bus that
a host->pci bridge (pcib) corresponds to.
Some have dual host->PCI bridges for the same logical pci bus (!), eg:
some of the RCC chipsets. This is a 32/64 bit 33/66MHz and dual pci
voltage motherboard so persumably there are electical or signalling
differences but they are otherwise the same logical bus.
The new PCI probe code however was getting somewhat upset about it and
ended up creating two pci bridges to the same logical bus, which caused
devices on that logical bus to appear and be probed twice.
The ACPI data on this box correctly identifies this stuff, so bring on
ACPI! :-)
pcib_set_bus() cannot be used on the new child because it is
meant to be used on the *pci* device (it looks at the parent internally)
not the pcib being added. Bite the bullet and use ivars for the bus
number to avoid any doubts about whether the softc is consistant between
probe and attach. This should not break the Alpha code.
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.
the PnP probe is merely a stub as we make assumptions about some of this
hardware before we have probed it.
Since these devices (with the exception of the speaker) are 'standard',
suppress output in the !bootverbose case to clean up the probe messages
somewhat.
- Add support for using the PCI BIOS functions for configuration space
accesses, and make this the default.
- Make PNPBIOS the default (obsoletes the PNPBIOS config option).
- Add two new boot-time tunables to disable each of the above.
chipset to be probed & attached on newer Dell PowerEdge servers, such as
the 2400 and 4400.
Reviewed by: dfr, msmith, jlemon
Tested by: hnokubi@yyy.or.jp (in a previous incantation)
Approved by: jkh
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
host->pci bridge specifically, then add a pcib0 device on the motherboard
for the pci bus to hang off.
Requested by: Anders Andersson <anders@sanyusan.se>
Obtained from: dfr
