Make PCI_ALLOW_UNSUPPORTED_IO_RANGE an option until the ISA address
problem is fixed at the bridge level. This is needed for some newer
laptops that have the cardbus bridge not on pci0.

Experimental patch to try to properly clip the range of the memory
request to one that's supported by the bridge. I'm not 100% sure this
is correct, but it makes it easier for the cardbus bridge to

Experimental patch to try to properly clip the range of the memory
request to one that's supported by the bridge. I'm not 100% sure this
is correct, but it makes it easier for the cardbus bridge to allocate
its memory.

Similar code is needed for the I/O range. Also, I'm not sure if I
should be doing this based on memory or pmemory (but likely should do
it based on some flag that tells us to prefetch or not).

Talked about a long time ago with: msmith

show more ...

Add a standard hack in the spirit of PCI_ENABLE_IO_MODES to allow systems
with weird PCI-PCI bridge configurations to work. Defining
PCI_ALLOW_UNSUPPORTED_IO_RANGE causes the sanity checks to pass e

Add a standard hack in the spirit of PCI_ENABLE_IO_MODES to allow systems
with weird PCI-PCI bridge configurations to work. Defining
PCI_ALLOW_UNSUPPORTED_IO_RANGE causes the sanity checks to pass even
with out of range values.

Reviewed by: msmith

show more ...

Next round of PCI subsystem updates:

- Break out the /dev/pci driver into a separate file.
- Kill the COMPAT_OLDPCI support.
- Make the EISA bridge attach a bit more like the old code; explicitly

Next round of PCI subsystem updates:

- Break out the /dev/pci driver into a separate file.
- Kill the COMPAT_OLDPCI support.
- Make the EISA bridge attach a bit more like the old code; explicitly
check for the existence of eisa0/isa0 and only attach if they don't
already exist. Only make one bus_generic_attach() pass over the
bridge, once both busses are attached. Note that the stupid Intel
bridge's class is entirely unpredictable.
- Add prototypes and re-layout the core PCI modules in line with
current coding standards (not a major whitespace change, just moving
the module data to the top of the file).
- Remove redundant type-2 bridge support from the core PCI code; the
PCI-CardBus code does this itself internally. Remove the now
entirely redundant header-class-specific support, as well as the
secondary and subordinate bus number fields. These are bridge
attributes now.
- Add support for PCI Extended Capabilities.
- Add support for PCI Power Management. The interface currently
allows a driver to query and set the power state of a device.
- Add helper functions to allow drivers to enable/disable busmastering
and the decoding of I/O and memory ranges.
- Use PCI_SLOTMAX and PCI_FUNCMAX rather than magic numbers in some
places.
- Make the PCI-PCI bridge code a little more paranoid about valid
I/O and memory decodes.
- Add some more PCI register definitions for the command and status
registers. Correct another bogus definition for type-1 bridges.

show more ...

- We have access to our own device_t here, so use pci_read_config
rather than finding our parent pcib and using its PCI_READ_CONFIG
method.

- Fix the defines for the 32-bit I/O decode registe

- We have access to our own device_t here, so use pci_read_config
rather than finding our parent pcib and using its PCI_READ_CONFIG
method.

- Fix the defines for the 32-bit I/O decode registers, and properly
process the 16-bit versions. Now we will correctly check that I/O
resources behind the bridge are going to be decoded.

- Bring the quirk for the Orion PCI:PCI bridge in here (since it
seems to want to set the secondary/supplementary bus numbers).

- Use PCI_SLOTMAX rather than a magic number.

show more ...

Next phase in the PCI subsystem cleanup.

- 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

Next phase in the PCI subsystem cleanup.

- 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.

show more ...

Merge from head at r201628.

# This hasn't been tested, and there are at least three bad commits
# that need to be backed out before the branch will be stable again.

Implement a rudimentary suspend/resume methods for PCI P2P bridge.

Reviewed by: jhb, imp

Revert junk from last commit. These are WIP and not ready (and don't
match the description of the last commit).

We no longer need to use d_thread_t, migrate to struct thread *.

- Merge from HEAD

Don't adjust ranges at all for subtractive bridges. The simple-minded
stuff we're doing is too simple-minded, so back it out for now.

Two fixes:
(1) Fix pcib_read/write_config prototypes.
(2) When contrainting a resource request for a 'subtractive' bridge,
it is important to select a range outside the base/limit
registers,

Two fixes:
(1) Fix pcib_read/write_config prototypes.
(2) When contrainting a resource request for a 'subtractive' bridge,
it is important to select a range outside the base/limit
registers, since those are the only values known to not
possibly work. On my HP laptop, the base bridge excludes I/O
ports 0xa000-0xafff, however that was the range we were passing
up the tree. Instead, when a range spans the "hole" we now
arbitrarily pick the range just above the hole to allocate from.

All of my rl and xl cards, at a minimum, started working again on this
laptop with those fixes.

show more ...

Style nit. Continued lines are indented 2 spaces in this file.

The config space registers holding the upper 32-bits of the prefetchable
memory area's base and limit are optional. The low 4-bits of the "low"
prefetchable registers indicates whether or not a 32-b

The config space registers holding the upper 32-bits of the prefetchable
memory area's base and limit are optional. The low 4-bits of the "low"
prefetchable registers indicates whether or not a 32-bit or 64-bit
region is supported. The PCI-PCI driver had been assuming that all bridges
supported a 64-bit region (and thus the two upper 32-bit registers). Fix
the driver to only use those registers if the low 4-bits of the "low"
registers indicate that a 64-bit region is supported. The PCI-PCI bridge
in the XBox happens to be a bridge that only supports a 32-bit region.

Reported by: rink
MFC after: 1 week

show more ...

Update a comment about not numbering pci busses. This may soon be
OBE, but was sitting around in one of my trees for a while...

Remove useless #if 1.

Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chi

Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.

This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.

show more ...

SATA device on some nForce based boards could get confused if MSI is not
used but MSI to HyperTransport IRQ mapping is enabled, and would act as
if MSI is turned on, resulting in interrupt loss.

Thi

SATA device on some nForce based boards could get confused if MSI is not
used but MSI to HyperTransport IRQ mapping is enabled, and would act as
if MSI is turned on, resulting in interrupt loss.

This commit will,
1. enable MSI mapping on a device only when MSI is enabled for that
device and the MSI address matches the HT mapping window.
2. enable MSI mapping on a bridge only when a downstream device is
allocated an MSI address in the mapping window

PR: kern/118842
Reviewed by: jhb
MFC after: 1 week

show more ...

Make the PCI code aware of PCI domains (aka PCI segments) so we can
support machines having multiple independently numbered PCI domains
and don't support reenumeration without ambiguity amongst the
d

Make the PCI code aware of PCI domains (aka PCI segments) so we can
support machines having multiple independently numbered PCI domains
and don't support reenumeration without ambiguity amongst the
devices as seen by the OS and represented by PCI location strings.
This includes introducing a function pci_find_dbsf(9) which works
like pci_find_bsf(9) but additionally takes a domain number argument
and limiting pci_find_bsf(9) to only search devices in domain 0 (the
only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are
changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order
to no longer report false positives when searching for siblings and
dupe devices in the same domain respectively.
Along with this change the sole host-PCI bridge driver converted to
actually make use of PCI domain support is uninorth(4), the others
continue to use domain 0 only for now and need to be converted as
appropriate later on.
Note that this means that the format of the location strings as used
by pciconf(8) has been changed and that consumers of <sys/pciio.h>
potentially need to be recompiled.

Suggested by: jhb
Reviewed by: grehan, jhb, marcel
Approved by: re (kensmith), jhb (PCI maintainer hat)

show more ...

Fix a typo in pcib_alloc_msi{x} which resulted in the
device's, not the bridge's, softc to be used to check the
PCIB_DISABLE_MSI flag. This resulted in randomly allowing
or denying MSI interrupts ba

Fix a typo in pcib_alloc_msi{x} which resulted in the
device's, not the bridge's, softc to be used to check the
PCIB_DISABLE_MSI flag. This resulted in randomly allowing
or denying MSI interrupts based on whatever value the driver
happened to store at sizeof(device_t) bytes into its softc.

I noticed this when I stopped getting MSI interrupts
after slighly re-arranging mxge's softc yesterday.

show more ...

Revamp the MSI/MSI-X code a bit to achieve two main goals:
- Simplify the amount of work that has be done for each architecture by
pushing more of the truly MI code down into the PCI bus driver.
-

Revamp the MSI/MSI-X code a bit to achieve two main goals:
- Simplify the amount of work that has be done for each architecture by
pushing more of the truly MI code down into the PCI bus driver.
- Don't bind MSI-X indicies to IRQs so that we can allow a driver to map
multiple MSI-X messages into a single IRQ when handling a message
shortage.

The changes include:
- Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus
to calculate the address and data values for a given MSI/MSI-X IRQ.
The x86 nexus drivers map this into a call to a new 'msi_map()' function
in msi.c that does the mapping.
- Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index'
parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge
of the MSI-X index for a given MSI-X IRQ.
- The PCI bus driver now stores more MSI-X state in a child's ivars.
Specifically, it now stores an array of IRQs (called "message vectors" in
the code) that have associated address and data values, and a small
virtual version of the MSI-X table that specifies the message vector
that a given MSI-X table entry uses. Sparse mappings are permitted in
the virtual table.
- The PCI bus driver now configures the MSI and MSI-X address/data
registers directly via custom bus_setup_intr() and bus_teardown_intr()
methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the
address and data values for a given message as needed. The MD code
no longer has to call back down into the PCI bus code to set these
values from the nexus' bus_setup_intr() handler.
- The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD
code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get
new values of the address and data fields for a given IRQ. The x86
MSI code uses this when an MSI IRQ is moved to a different CPU, requiring
a new value of the 'address' field.
- The x86 MSI psuedo-driver loses a lot of code, and in fact the separate
MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver
since the only remaining diff between the two is a substring in a
bootverbose printf.
- The PCI bus driver will now restore MSI-X state (including programming
entries in the MSI-X table) on device resume.
- The interface for pci_remap_msix() has changed. Instead of accepting
indices for the allocated vectors, it accepts a mini-virtual table
(with a new length parameter). This table is an array of u_ints, where
each value specifies which allocated message vector to use for the
corresponding MSI-X message. A vector of 0 forces a message to not
have an associated IRQ. The device may choose to only use some of the
IRQs assigned, in which case the unused IRQs must be at the "end" and
will be released back to the system. This allows a driver to use the
same remap table for different shortage values. For example, if a driver
wants 4 messages, it can use the same remap table (which only uses the
first two messages) for the cases when it only gets 2 or 3 messages and
in the latter case the PCI bus will release the 3rd IRQ back to the
system.

MFC after: 1 month

show more ...

- Add missing constants for subclasses.
- Add a few progif constants as well.

Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support.
- First off, device drivers really do need to know if they are allocating
MSI or MSI-X messages. MSI requires allocating

Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support.
- First off, device drivers really do need to know if they are allocating
MSI or MSI-X messages. MSI requires allocating powerof2() messages for
example where MSI-X does not. To address this, split out the MSI-X
support from pci_msi_count() and pci_alloc_msi() into new driver-visible
functions pci_msix_count() and pci_alloc_msix(). As a result,
pci_msi_count() now just returns a count of the max supported MSI
messages for the device, and pci_alloc_msi() only tries to allocate MSI
messages. To get a count of the max supported MSI-X messages, use
pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix().
pci_release_msi() still handles both MSI and MSI-X messages, however.
As a result of this change, drivers using the existing API will only
use MSI messages and will no longer try to use MSI-X messages.
- Because MSI-X allows for each message to have its own data and address
values (and thus does not require all of the messages to have their
MD vectors allocated as a group), some devices allow for "sparse" use
of MSI-X message slots. For example, if a device supports 8 messages
but the OS is only able to allocate 2 messages, the device may make the
best use of 2 IRQs if it enables the messages at slots 1 and 4 rather
than default of using the first N slots (or indicies) at 1 and 2. To
support this, add a new pci_remap_msix() function that a driver may call
after a successful pci_alloc_msix() (but before allocating any of the
SYS_RES_IRQ resources) to allow the allocated IRQ resources to be
assigned to different message indices. For example, from the earlier
example, after pci_alloc_msix() returned a value of 2, the driver would
call pci_remap_msix() passing in array of integers { 1, 4 } as the
new message indices to use. The rid's for the SYS_RES_IRQ resources
will always match the message indices. Thus, after the call to
pci_remap_msix() the driver would be able to access the first message
in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at
SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based
rather than 0-based so that they will always correspond to the rid
values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt).
To support this API, a new PCIB_REMAP_MSIX() method was added to the
pcib interface to change the message index for a single IRQ.

Tested by: scottl

show more ...

- Add a new flag to the PCI-PCI driver to disable MSI on devices behind the
bridge if it doesn't pass MSI messages up correctly. We set the flag
in pcib_attach() if the device ID is disabled via

- Add a new flag to the PCI-PCI driver to disable MSI on devices behind the
bridge if it doesn't pass MSI messages up correctly. We set the flag
in pcib_attach() if the device ID is disabled via a PCI quirk.
- Disable MSI for devices behind the AMD 8131 HT-PCIX bridge. Linux has
the same quirk.

Tested by: no one despite repeated calls for testers

show more ...