| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
goes after the npx/apm devices and any other motherboard devices that
may get added down the track.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as PCI->HOST bridges on my (440BX) box.
My change is to remove the test at the beginning entirely, letting the
switch on the device ID happen first. If the device ID is unknown, then
(in the default case) check for the generic PCIS_BRIDGE_HOST tag. This
should allow wierd cases (eg: wpaul's IMS VL bridge) to work by using the
id override. This strategy is more in line with the other PCI match
methods we use elsewhere,
I only have a limited testbed, but having my USB etc devices detected as
PCI->HOST bridges doesn't look good.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correctly. It has the following code:
if (class != PCIC_BRIDGE || subclass != PCIS_BRIDGE_HOST)
return NULL;
My 486 has an Integrated Micro Solutions PCI bridge which identifies
itself as subclass PCIS_BRIDGE_OTHER, not PCIS_BRIDGE_HOST. Consequently,
it gets ignored. In my opinion, the correct test should be:
if ((class != PCIC_BRIDGE) && (subclass != PCIS_BRIDGE_HOST))
return NULL;
That way the test still succeeds because the chip's class is PCIC_BRIDGE.
Clearly it's not reasonable to expect all host to PCI bridges to always
have a subclass of PCIS_BRIDGE_HOST since I've got one that doesn't.
This way the sanity test should remain relatively sane while still allowing
some oddball yet correct hardware to work. If somebody has a better way
to do it, go ahead and tweak the test, but be aware that
class == PCIC_BRIDGE and subclass == PCIS_BRIDGE_OTHER is a valid case.
While I was here, I also added an explicit ID string for the IMS chipset.
I also dealt with a minor style nit: it's bad karma not to have a default
case for your switch statements, but the one in this routine doesn't have
one. The default string of "Host to PCI bridge" is now assigned in a
default case of the switch statement instead of initializing "s" with the
string before the switch and then not having any default case.
|
|
|
|
|
| |
to. This might have caused interesting things on non-PCI hardware if
PCI was compiled in.
|
|
|
|
|
|
|
| |
This is only partially complete, but allows 450NX-based systems with
more than one PCI bus to be used again.
Submitted by: dfr
|
|
|
|
|
| |
to pcibus.c. pci_cfgopen() becomes static and there are no more
bus #ifdef's in nexus.c.
|
|
|
|
|
|
|
|
|
| |
It failed to recognize the PCI bus in a system that had only an
old chip-set (class code 000000) and a Cyclom multiport serial
card on PCI bus 0, but no VGA card or disk or network controller.
PR: i386/5300
Submitted by: Nickolay N. Dudorov <nnd@itfs.nsk.su>
|
| |
|
|
|
|
|
|
| |
Adjust the data port address by adding the two low order bits of
the register number. The address port takes only a word address
(i.e. ignores the two low order bits written to it).
|
| |
|
|
|
|
|
|
|
| |
mode 1. Omission of this bit makes all config register accesses fail in
on recent chip sets ...
(The problem was reported and debug output provided by: Steve Passe)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
|
| |
|
| |
|
| |
|
|
|
|
|
| |
on bus 0.
This fixes problems with EISA-only systems mistakenly being assumed to support PCI.
|
|
|
|
| |
ready for it yet.
|
|
|
|
| |
only 3 or 4 warnings) when pb_maxirq went away.
|
|
|
|
|
|
|
|
| |
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
|
|
|
|
|
|
|
|
|
|
|
| |
code.
Reviewed by: bde
[
Bruce suggest removing the macros completely, but I'm not up to that
task quite yet.
]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(1) deleted #if 0
pc98/pc98/mse.c
(2) hold per-unit I/O ports in ed_softc
pc98/pc98/if_ed.c
pc98/pc98/if_ed98.h
(3) merge more files by segregating changes into headers.
new file (moved from pc98/pc98):
i386/isa/aic_98.h
deleted:
well, it's already in the commit message so I won't repeat the
long list here ;)
Submitted by: The FreeBSD(98) Development Team
|
|
|
|
|
|
|
| |
is only used by the icu support modules and by a few drivers that know
too much about the icu (most only use it to convert `n' to `IRQn'). isa.h
is only used by ioconf.c and by a few drivers that know too much about
isa addresses (a few have to, because config is deficient).
|
|
|
|
|
| |
whether a system could possibly support PCI configuration mechanism 1
(or whether it rather is an EISA only system ...).
|
| |
|
|
|
|
| |
being declared in the wrong place.
|
|
|
|
|
|
| |
in the clk0 counter.
Reviewed by: s
|
| |
|
|
|
|
|
|
|
|
| |
#includes to get prototypes.
pci now uses a different interrupt handler type for interrupts that it
dispatches and the isa interrupt handler type for the interrupts that
it handles.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
accesses after the BIOS bus scan. The previous revision made the assumption,
that every PCI motherboard did ...
Change the test on the initial value of the CONF1_ADDR_PORT register in a way
that makes the probe succeed on triton based motherboards, without breaking
the EISA motherboard that has some non-PCI register at the same address.
|
|
|
|
|
|
|
|
|
|
| |
Require the state of the configuration enable bits to be OFF assuming
that the BIOS left them that way, as it should anyway to avoid bad things
to happen.
The tests themselves are copied from the previous release, with the
exception of CONF1_ENABLE_MSK1 having the LSB set. This bit should be
read back as '0', since only DWORD addresses are legal.
|
| |
|
|
|
|
|
| |
- try to make sure there is any kind of PCI device
- if there is anything at port 0x0cf8, then check for mech. 1 or 2
|
|
|
|
|
|
|
| |
Changes relative to 1.12:
- Put extra instruction between outl()/inl() sequence to prevent the
old value being read back because of the bus capacitance.
- Additional check for existence of register at CONF2_ENABLE_PORT.
|
|
|
|
|
|
|
|
|
| |
there is a PCI bus at all) ...
- Do not expect the chip sets to follow even very clearly expressed
requirements of the PCI 2.0 spec.
- Do not read back the value just written to an I/O port without making
sure that some other data have crossed the bus in between ...
|
|
|
|
|
| |
Scan for devices instead of assuming that device 0 is present on bus 0
of every PCI motherboard.
|
|
|
|
|
| |
that use configuration mode 1, but still violate the PCI 2.0 specs ...
(Required for the Compaq Proliant, for example.)
|
|
|
|
|
|
| |
Make it less strict ...
Submitted by: NIIMI Satoshi <sa2c@and.or.jp>
|
|
|
|
|
|
| |
fail on new hardware (Compaq Prolinea and Compaq Prosignea), and that
doesn't erroneously identify old mech. 2 chip sets as using mech. 1.
(See section 3.6.4.1.1 of the PCI bus specs rev. 2.0)
|
| |
|
|
|
|
| |
Submitted by: Wolfgang Stanglmeier <wolf@kintaro.cologne.de>
|
|
|
|
| |
Submitted by: Michael Reifenberger <root@rz-wb.fh-sw.de>
|
|
|
|
|
|
| |
Supports shared PCI interrupts.
Submitted by: Wolfgang Stanglmeier <wolf@kintaro.cologne.de>
|
|
|
|
| |
nearby #include inconsistencies.
|
|
|
|
|
| |
Reviewed by: se
Submitted by: seb@erix.ericsson.se (Sebastian Strollo)
|
|
|
|
|
| |
Reviewed by: se
Submitted by: wolf (Wolfgang Stanglmeier)
|
|
|
|
|
|
| |
Submitted by: wolf (Wolfgang Stanglmeier)
New ISA dependend file for PCI bus support.
Replaces sys/i386/pci/pcibios.c.
|
|
|
|
| |
#define to a more appropriate name.
|
| |
|