Commit Graph

88 Commits

Author SHA1 Message Date
Hans Petter Selasky
af3b2549c4 Pull in r267961 and r267973 again. Fix for issues reported will follow. 2014-06-28 03:56:17 +00:00
Glen Barber
37a107a407 Revert r267961, r267973:
These changes prevent sysctl(8) from returning proper output,
such as:

 1) no output from sysctl(8)
 2) erroneously returning ENOMEM with tools like truss(1)
    or uname(1)
 truss: can not get etype: Cannot allocate memory
2014-06-27 22:05:21 +00:00
Hans Petter Selasky
3da1cf1e88 Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after:	2 weeks
Sponsored by:	Mellanox Technologies
2014-06-27 16:33:43 +00:00
Ryan Stone
55d3ea1731 Add support for PCIe ARI
PCIe Alternate RID Interpretation (ARI) is an optional feature that
allows devices to have up to 256 different functions.  It is
implemented by always setting the PCI slot number to 0 and
re-purposing the 5 bits used to encode the slot number to instead
contain the function number.  Combined with the original 3 bits
allocated for the function number, this allows for 256 functions.

This is enabled by default, but it's expected to be a no-op on currently
supported hardware.  It's a prerequisite for supporting PCI SR-IOV, and
I want the ARI support to go in early to help shake out any bugs in it.
ARI can be disabled by setting the tunable hw.pci.enable_ari=0.

Reviewed by:	kib
MFC after:	2 months
Sponsored by:	Sandvine Inc.
2014-04-01 16:02:02 +00:00
Ryan Stone
5605a99e36 Add a method to get the PCI RID for a device.
Reviewed by:	kib
MFC after:	2 months
Sponsored by:	Sandvine Inc.
2014-04-01 15:47:24 +00:00
Ryan Stone
7036ae46bf Revert PCI RID changes.
My PCI RID changes somehow got intermixed with my PCI ARI patch when I
committed it.  I may have accidentally applied a patch to a non-clean
working tree.  Revert everything while I figure out what went wrong.

Pointy hat to: rstone
2014-04-01 15:06:03 +00:00
Ryan Stone
d773f48b1e Add a method to get the PCI Routing ID for a device
Reviewed by:	kib
Sponsored by:	Sandvine, Inc
2014-04-01 14:49:25 +00:00
John Baldwin
4edef187b8 Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge
I/O windows, the default is to preserve the firmware-assigned resources.
PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture
defines a PCI_RES_BUS resource type.
- Add a helper API to create top-level PCI bus resource managers for each
  PCI domain/segment.  Host-PCI bridge drivers use this API to allocate
  bus numbers from their associated domain.
- Change the PCI bus and CardBus drivers to allocate a bus resource for
  their bus number from the parent PCI bridge device.
- Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the
  full range of bus numbers from secbus to subbus from their parent bridge.
  The drivers also always program their primary bus register.  The bridge
  drivers also support growing their bus range by extending the bus resource
  and updating subbus to match the larger range.
- Add support for managing PCI bus resources to the Host-PCI bridge drivers
  used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib).
- Define a PCI_RES_BUS resource type for amd64 and i386.

Reviewed by:	imp
MFC after:	1 month
2014-02-12 04:30:37 +00:00
John Baldwin
0070c94be9 Add two tunables to ignore certain firmware-assigned resources. These
are mostly useful for debugging.
- hw.pci.clear_bars ignores all firmware-assigned ranges for BARs when
  set.
- hw.pci.clear_pcib ignores all firmware-assigned ranges for PCI-PCI
  bridge I/O windows when set.

MFC after:	1 week
2014-02-05 20:52:12 +00:00
John Baldwin
c825d4dc50 Properly handle I/O windows in bridges with the ISA enable bit set. These
beasts still exist unfortunately.  More details can be found in other
references, but the short version is that bridges with this bit set ignore
I/O port ranges that alias to valid ISA I/O port ranges.  In the driver
this requires not allocating these alias regions from the parent device
(so they are free to be acquired by ISA devices), and ensuring no child
devices use resources from these alias regions.
- Change the pcib_window structure to allow for an array of backing
  resources rather than a single resource and update the existing code
  to cope with this.  Some of the coping requires using the saved
  base and limit values in pcib_window instead of using rman operations
  on the backing resource.
- Add special handling for allocating and adjusting the I/O port window
  of an ISA-enabled bridge to only allocate the non-alias ranges and
  add those to the associated resource manager.
- Reject I/O port allocations for a fixed request that conflicts with an
  ISA alias range.
- Remove the "no prefected decode" verbose printf during boot.  The absence
  of a "prefetched decode" line is sufficient.
- Replace the "subtractively decoded bridge" verbose printf with a single
  printf that lists all the "special" decoding modes of a bridge: ISA,
  subtractive, and VGA.
- Add a custom bus_release_resource() method to the PCI bus driver so that
  it can properly free resources for I/O windows of PCI-PCI bridges.
  (These resources are not stored in the bridge device's resource list.)

PR:		misc/179033
MFC after:	2 weeks
2013-07-18 15:17:11 +00:00
Marius Strobl
68e9cbd385 - As it turns out, not only MSI-X is broken for devices passed through by
VMware up to at least ESXi 5.1. Actually, using INTx in that case instead
  may still result in interrupt storms, with MSI being the only working
  option in some configurations. So introduce a PCI_QUIRK_DISABLE_MSIX quirk
  which only blacklists MSI-X but not also MSI and use it for the VMware
  PCI-PCI-bridges. Note that, currently, we still assume that if MSI doesn't
  work, MSI-X won't work either - but that's part of the internal logic and
  not guaranteed as part of the API contract. While at it, add and employ
  a pci_has_quirk() helper.
  Reported and tested by: Paul Bucher
- Use NULL instead of 0 for pointers.

Submitted by:	jhb (mostly)
Approved by:	jhb
MFC after:	3 days
2013-07-09 23:12:26 +00:00
John Baldwin
ef8881526b Explicitly enable busmastering on PCI-PCI bridges. Transactions initiated
on the secondary side of a bridge will not be propagated to the primary
bus unless this is enabled.  Busmastering is not enabled by default (we
have relied on firmware to set this bit to date).  The OS needs to set it
for any bridges not configured by system firmware.

Tested by:	Steve Polyack  korvus comcast net
MFC after:	2 weeks
2012-08-06 19:49:57 +00:00
Marius Strobl
a6c8226584 For subtractively decoding bridges, don't try to grow windows but pass
the request up the tree in order to be on the safe side. Growing windows
in this case would mean to switch resources to positive decoding and
it's unclear how to correctly handle this. At least with ALi/ULi M5249
PCI-PCI bridges, this also just doesn't work out of the box.

Reviewed by:	jhb
MFC after:	3 days
2012-06-27 22:17:52 +00:00
John Baldwin
a7b5acac1a Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' in
pcib_grow_window().  This makes the code slightly easier to read and
prevents the type of bug fixed in r237271.

MFC after:	3 days
2012-06-19 16:06:27 +00:00
John Baldwin
1ba9eae287 Fix another off-by-one error in the previous fix so that the new start
address is properly aligned.  While here, use a simpler expression to
align the new end address that we use elsewhere for aligning the end.
2012-06-19 15:15:35 +00:00
John Baldwin
ddac8cc944 Fix a couple of bugs that prevented windows in PCI-PCI bridges from
growing "downward" (moving the start address down).  First, an off by
one error caused the end address to be moved down an extra alignment
chunk unnecessarily.  Second, when aligning the new candidate starting
address, the wrong bits were masked off.

Tested by:	Andrey Zonov  andrey zonov org
MFC after:	3 days
2012-06-13 15:04:50 +00:00
Marius Strobl
4b7ec27007 - There's no need to overwrite the default device method with the default
one. Interestingly, these are actually the default for quite some time
  (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
  since r52045) but even recently added device drivers do this unnecessarily.
  Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
  Discussed with: jhb
- Also while at it, use __FBSDID.
2011-11-22 21:28:20 +00:00
John Baldwin
34ff71eecd Respect the BIOS/firmware's notion of acceptable address ranges for PCI
resource allocation on x86 platforms:
- Add a new helper API that Host-PCI bridge drivers can use to restrict
  resource allocation requests to a set of address ranges for different
  resource types.
- For the ACPI Host-PCI bridge driver, use Producer address range resources
  in _CRS to enumerate valid address ranges for a given Host-PCI bridge.
  This can be disabled by including "hostres" in the debug.acpi.disabled
  tunable.
- For the MPTable Host-PCI bridge driver, use entries in the extended
  MPTable to determine the valid address ranges for a given Host-PCI
  bridge.  This required adding code to parse extended table entries.

Similar to the new PCI-PCI bridge driver, these changes are only enabled
if the NEW_PCIB kernel option is enabled (which is enabled by default on
amd64 and i386).

Approved by:	re (kib)
2011-07-15 21:08:58 +00:00
John Baldwin
a27d4bdc9f Properly align the end of a candidate back region based on the window's
granularity when growing a PCI-PCI window up.

Tested by:	dougb
MFC after:	3 days
2011-07-12 13:28:39 +00:00
John Baldwin
0dbe859d2f Split out host_pcib_get_busno() from the generic PCI-PCI bridge driver to
start a new file that will hold utility APIs used by various Host-PCI
bridge drivers and drivers that provide PCI domains.
2011-06-24 21:39:38 +00:00
John Baldwin
a49dcb469c Fix some off-by-one errors with the ending address of candidate regions
when attempting to grow a window.
2011-06-10 13:24:56 +00:00
John Baldwin
83c41143ca Reimplement how PCI-PCI bridges manage their I/O windows. Previously the
driver would verify that requests for child devices were confined to any
existing I/O windows, but the driver relied on the firmware to initialize
the windows and would never grow the windows for new requests.  Now the
driver actively manages the I/O windows.

This is implemented by allocating a bus resource for each I/O window from
the parent PCI bus and suballocating that resource to child devices.  The
suballocations are managed by creating an rman for each I/O window.  The
suballocated resources are mapped by passing the bus_activate_resource()
call up to the parent PCI bus.  Windows are grown when needed by using
bus_adjust_resource() to adjust the resource allocated from the parent PCI
bus.  If the adjust request succeeds, the window is adjusted and the
suballocation request for the child device is retried.

When growing a window, the rman_first_free_region() and
rman_last_free_region() routines are used to determine if the front or
end of the existing I/O window is free.  From using that, the smallest
ranges that need to be added to either the front or back of the window
are computed.  The driver will first try to grow the window in whichever
direction requires the smallest growth first followed by the other
direction if that fails.

Subtractive bridges will first attempt to satisfy requests for child
resources from I/O windows (including attempts to grow the windows).  If
that fails, the request is passed up to the parent PCI bus directly
however.

The PCI-PCI bridge driver will try to use firmware-assigned ranges for
child BARs first and only allocate a "fresh" range if that specific range
cannot be accommodated in the I/O window.  This allows systems where the
firmware assigns resources during boot but later wipes the I/O windows
(some ACPI BIOSen are known to do this) to "rediscover" the original I/O
window ranges.

The ACPI Host-PCI bridge driver has been adjusted to correctly honor
hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge
makes a wildcard request for an I/O window range.

The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option
is enabled.  This is a transition aide to allow platforms that do not
yet support bus_activate_resource() and bus_adjust_resource() in their
Host-PCI bridge drivers (and possibly other drivers as needed) to use the
old driver for now.  Once all platforms support the new driver, the
kernel option and old driver will be removed.

PR:		kern/143874 kern/149306
Tested by:	mav
2011-05-03 17:37:24 +00:00
John Baldwin
d2c9344ff9 Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver,
generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge
drivers.
2011-05-02 14:13:12 +00:00
John Baldwin
9d76324839 Add device IDs for two more ServerWorks Host-PCI bridges so that we can
read their starting PCI bus number for older systems that do not support
ACPI (or have a broken _BBN method).

PR:		kern/148108
MFC after:	1 week
2010-11-25 15:42:33 +00:00
Jung-uk Kim
f3e0b10973 Introduce a new tunable 'hw.pci.do_power_suspend'. This tunable lets you
avoid PCI power state transition from D0 to D3 for suspending case.  Default
is 1 or enabled.
2010-10-20 16:47:09 +00:00
Jung-uk Kim
347263c935 Do not apply do_power_resume for suspending P2P bridge as we did in r214064. 2010-10-20 16:40:14 +00:00
John Baldwin
62508c531e Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This
method is used by the PCI bus driver to query the power management system
to determine the proper device state to be used for a device during suspend
and resume.  For the ACPI PCI bridge drivers this calls
acpi_device_pwr_for_sleep().  This removes ACPI-specific knowledge from
the PCI and PCI-PCI bridge drivers.

Reviewed by:	jkim
2010-08-17 15:44:52 +00:00
Jung-uk Kim
e36af2929a Implement a rudimentary suspend/resume methods for PCI P2P bridge.
Reviewed by:	jhb, imp
2009-12-10 01:01:53 +00:00
Warner Losh
89c81b88f1 Revert junk from last commit. These are WIP and not ready (and don't
match the description of the last commit).
2009-05-20 22:00:39 +00:00
Warner Losh
00b4e54ae7 We no longer need to use d_thread_t, migrate to struct thread *. 2009-05-20 17:29:21 +00:00
Warner Losh
9dffe835eb 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.
2009-03-15 06:40:57 +00:00
Warner Losh
795dceffa2 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.
2009-03-14 14:08:53 +00:00
Warner Losh
7589f19e81 Style nit. Continued lines are indented 2 spaces in this file. 2008-09-03 06:57:21 +00:00
John Baldwin
9c0e9e988e 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
2008-08-20 18:29:59 +00:00
Warner Losh
7e178674ff 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...
2008-08-17 17:34:07 +00:00
Warner Losh
e4e130244d Remove useless #if 1. 2008-08-16 21:51:54 +00:00
Warner Losh
abf07f13fd 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.
2008-08-16 20:18:40 +00:00
Luoqi Chen
4522ac77de 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
2008-07-23 09:44:36 +00:00
Marius Strobl
55aaf894e8 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)
2007-09-30 11:05:18 +00:00
Andrew Gallatin
bd82bbb145 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.
2007-05-23 15:31:00 +00:00
John Baldwin
e706f7f0c7 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
2007-05-02 17:50:36 +00:00
John Baldwin
657d9f9f55 - Add missing constants for subclasses.
- Add a few progif constants as well.
2007-03-31 20:41:00 +00:00
John Baldwin
5fe82bca57 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
2007-01-22 21:48:44 +00:00
John Baldwin
22bf1c7fb0 - 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
2007-01-13 04:57:37 +00:00
John Baldwin
9bf4c9c1b0 First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
  to provide the device driver visible API:
  - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI().  '*count'
    here is an in and out parameter.  The driver stores the desired number
    of messages in '*count' before calling the function.  On success,
    '*count' holds the number of messages allocated to the device.  Also on
    success, the driver can access the messages as SYS_RES_IRQ resources
    starting at rid 1.  Note that the legacy INTx interrupt resource will
    not be available when using MSI.  Note that this function will allocate
    either MSI or MSI-X messages depending on the devices capabilities and
    the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables.  Also note
    that the driver should activate the memory resource that holds the
    MSI-X table and pending bit array (PBA) before calling this function
    if the device supports MSI-X.
  - pci_release_msi(dev) backed by PCI_RELEASE_MSI().  This function
    releases the messages allocated for this device.  All of the
    SYS_RES_IRQ resources need to be released for this function to succeed.
  - pci_msi_count(dev) backed by PCI_MSI_COUNT().  This function returns
    the maximum number of MSI or MSI-X messages supported by this device.
    MSI-X is preferred if present, but this function will honor the
    'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables.  This function
    should return the largest value that pci_alloc_msi() can return
    (assuming the MD code is able to allocate sufficient backing resources
    for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
  PCI bus driver.  (The various other PCI bus drivers such as for ACPI and
  OFW will inherit these default implementations.)  This default
  implementation depends on 4 new pcib_if methods that bubble up through
  the PCI bridges to the MD code to allocate IRQ values and perform any
  needed MD setup code needed:
  - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
  - PCIB_RELEASE_MSI() releases a group of MSI messages.
  - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
  - PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
  request up to the parent bus's parent bridge driver and use the
  default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
  interrupts:
  - pci_enable_msi(dev, address, data) programs the MSI capability address
    and data registers for a group of MSI messages
  - pci_enable_msix(dev, index, address, data) initializes a single MSI-X
    message in the MSI-X table
  - pci_mask_msix(dev, index) masks a single MSI-X message
  - pci_unmask_msix(dev, index) unmasks a single MSI-X message
  - pci_pending_msix(dev, index) returns true if the specified MSI-X
    message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
  block in a PCI devices ivars and restore the values when a device is
  resumed.  Note that the MSI-X table is not currently restored during
  resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
  across in the pci_cfgreg block in the ivars for PCI devices.

Tested on:	em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by:	scottl, grehan, jfv
MFC after:	2 months
2006-11-13 21:47:30 +00:00
John Baldwin
2604383634 Don't try to print a NULL string during boot. If a device doesn't have a
valid name yet, just omit the name during the bootverbose printfs.

MFC after:	1 week
2006-11-09 18:04:53 +00:00
Warner Losh
b0a2d4b8a9 More fully support 64-bit bars. Prior to this commit, we supported
only those bars that had addresses assigned by the BIOS and where the
bridges were properly programmed.  Now even unprogrammed ones work.
This was needed for sun4v.  We still only implement up to 2GB memory
ranges, even for 64-bit bars.  PCI standards at least through 2.2 say
that this is the max (or 1GB is, I only know it is < 32bits).

o Always define pci_addr_t as uint64_t.  A pci address is always 64-bits,
  but some hosts can't address all of them.
o Preserve the upper half of the 64-bit word during resource probing.
o Test to make sure that 64-bit values can fit in a u_long (true on some
  platforms, but not others).  Don't use those that can't.
o minor pedantry about data sizes.
o Better bridge resource reporting in bootverbose case.
o Minor formatting changes to cope with different data types on different
  platforms.

Submitted by: jmg, with many changes by me to fully support 64-bit
addresses.
2006-10-30 19:18:46 +00:00
Warner Losh
413d6375d7 Remove redundant casts. The casts inside the macros should be
sufficient (or fixed if not).
2006-10-12 03:05:45 +00:00
Jung-uk Kim
1def0ca64d Free allocated environment variables after use.
Coverity ID:	366
Found by:	Coverity Prevent
2006-04-21 19:35:03 +00:00
John Baldwin
04dda605c5 - Make pcib_devclass private to sys/dev/pci/pci_pci.c and change all the
various pcib drivers to use their own private devclass_t variables for
  their modules.
- Use the DEFINE_CLASS_0() macro to declare drivers for the various pcib
  drivers while I'm here.
2006-01-06 19:22:19 +00:00