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.
- Implement bus_adjust_resource() methods as far as necessary and in non-PCI
bridge drivers as far as feasible without rototilling them.
- As NEW_PCIB does a layering violation by activating resources at layers
above pci(4) without previously bubbling up their allocation there, move
the assignment of bus tags and handles from the bus_alloc_resource() to
the bus_activate_resource() methods like at least the other NEW_PCIB
enabled architectures do. This is somewhat unfortunate as previously
sparc64 (ab)used resource activation to indicate whether SYS_RES_MEMORY
resources should be mapped into KVA, which is only necessary if their
going to be accessed via the pointer returned from rman_get_virtual() but
not for bus_space(9) as the later always uses physical access on sparc64.
Besides wasting KVA if we always map in SYS_RES_MEMORY resources, a driver
also may deliberately not map them in if the firmware already has done so,
possibly in a special way. So in order to still allow a driver to decide
whether a SYS_RES_MEMORY resource should be mapped into KVA we let it
indicate that by calling bus_space_map(9) with BUS_SPACE_MAP_LINEAR as
actually documented in the bus_space(9) page. This is implemented by
allocating a separate bus tag per SYS_RES_MEMORY resource and passing the
resource via the previously unused bus tag cookie so we later on can call
rman_set_virtual() in sparc64_bus_mem_map(). As a side effect this now
also allows to actually indicate that a SYS_RES_MEMORY resource should be
mapped in as cacheable and/or read-only via BUS_SPACE_MAP_CACHEABLE and
BUS_SPACE_MAP_READONLY respectively.
- Do some minor cleanup like taking advantage of rman_init_from_resource(),
factor out the common part of bus tag allocation into a newly added
sparc64_alloc_bus_tag(), hook up some missing newbus methods and replace
some homegrown versions with the generic counterparts etc.
- While at it, let apb_attach() (which can't use the generic NEW_PCIB code
as APB bridges just don't have the base and limit registers implemented)
regarding the config space registers cached in pcib_softc and the SYSCTL
reporting nodes set up.
also use the streaming buffer of pre version 5/revision 2.3 hardware as
long as we stay away from context flushes (which iommu(4) so far doesn't
take advantage of). OpenSolaris does the same.
cycle mode as timecounter just works fine. My best guess is that a firmware
update has fixed this, check at run-time whether it advances and use a
positive quality if it does. The latter will cause this timecounter to be
used instead of the tick counter based one, which just sucks for SMP.
- Remove a redundant NULL assignment from the timecounter initialization.
as STX_CTRL_PERF_CNT_CNT0_SHIFT actually is zero, if we were using the
second counter in the upper 32 bits this would be required though as the MI
timecounter code doesn't support 64-bit counters/counter registers.
- Remove a redundant NULL assignment from the timecounter initialization.
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
the iommu(4) provided one, i.e. in case of Hummingbird and Sabre bridges,
otherwise just use the iommu(4) one. This also fixes a bug introduced in
r220039 which caused an empty DMA method table to be used for the second
of a pair of Psycho bridges.
syncing for Hummingbird and Sabre bridges should be applied with every
BUS_DMASYNC_POSTREAD instead of in a wrapper around interrupt handlers
for devices behind PCI-PCI bridges only as suggested by the documentation
(code for the latter actually exists in OpenSolaris but is disabled by
default), which also makes more sense.
- Take advantage of the ofw_pci_setup_device method introduced in r220038
for disabling bus parking for certain EBus bridges in order to
- Mark some unused parameters as such.
register changes when compiled with SCHIZO_DEBUG and take advantage
of them.
- Add support for the XMITS Fireplane/Safari to PCI-X bridges. I tought
I'd need this for a Sun Fire 3800, which then turned out to not being
equipped with such a bridge though. The support for these should be
complete but given that it hasn't actually been tested probing is
disabled for now.
This required a way to alter the XMITS configuration in case a PCI-X
device is found further down the device tree so the sparc64 specific
ofw_pci kobj was revived with a ofw_pci_setup_device method, which is
called by the ofw_pcibus code for every device added.
- A closer inspection of the OpenSolaris code indicates that consistent
DMA flushing/syncing as well as the block store workaround should be
applied with every BUS_DMASYNC_POSTREAD instead of in a wrapper around
interrupt handlers for devices behind PCI-PCI bridges only as suggested
by the documentation (code for the latter actually exists in OpenSolaris
but is disabled by default), which also makes more sense.
- Add a workaround for Casinni/Skyhawk combinations. Chances are that
this solves the crashes seen when using the the on-board Casinni NICs
of Sun Fire V480 equipped with centerplanes other than 501-6780 or
501-6790. This also takes advantage of the ofw_pci_setup_device method.
- Mark some unused parameters as such.
- A closer inspection of the OpenSolaris code indicates the block store
workaround is only necessary in case of BUS_DMASYNC_POSTREAD.
- Mark some unused parameters as such.
and switch sparc64 to use the first one for bus error filter handlers of
bridge drivers instead of (ab)using INTR_FAST for that so we eventually
can get rid of the latter.
Reviewed by: jhb
MFC after: 1 month
implementation.
- Revert the Sun Fire V890 WAR of r205254. Instead let schizo_pci_bus()
only panic in case of fatal errors as the interrupt triggered by the
error the firmware of these and also Sun Fire 280R with version 7
Schizo caused may happen as late as using the HBA and not only prior
to touching the PCI bus (in the former case the actual error still is
fatal but we clear it before touching the PCI bus).
While at it count and export non-fatal error interrupts via sysctl(9).
- Remove unnecessary locking from schizo_ue().
StarCat systems which provides time-of-day services for both as well as
console service for Serengeti, i.e. Sun Fire V1280. While the latter is
described with a device type of serial in the OFW device tree, it isn't
actually an UART. Nevertheless the console service is handled by uart(4)
as this allowed to re-use quite a bit of MD and MI code. Actually, this
idea is stolen from Linux which interfaces the sun4v hypervisor console
with the Linux counterpart of uart(4).
provides no ino-bitmap properties so forge them using the default set
of controller interrupts and let schizo_setup_intr() take care of the
children, hoping for non-fancy routing.
- Add quirk handling for Sun Fire V890. When booting these machines from
disk a Schizo comes up with PCI error residing which triggers as soon
as we register schizo_pci_bus() even when clearing it from all involved
registers (it's no longer indicated once we're in schizo_pci_bus()
though). Thus make PCI bus errors non-fatal until we actually touch the
bus. With this change schizo_pci_bus() typically triggers once during
attach in this case. Obviously this approach isn't exactly race free
but it's about the best we can do about this problem as we're not
guaranteed that the interrupt will actually trigger on V890 either, as
it certainly doesn't when for example netbooting them.
indicating an already initialized lock.
- Check for an empty MSI/MSI-X queue entry before asserting that we have
received a MSI/MSI-X message in order to not panic in case of stray MSI/
MSI-X queue interrupts which may happen in case of using an interrupt
handler rather than a filter.
MFC after: 3 days
device in the table based on the count rather than the maxcount.
Also the previous code didn't work properly as it would have been
necessary to reserve the entire maxcount range in order keep later
requests from filling the spare MSIs between count and maxcount,
which would be complicated to unreserve in fire_release_msi().
- For MSIs with filters rather than handlers only don't clear the
event queue interrupt via fire_intr_clear() since given that these
are executed directly would clear it while we're still processing
the event queue, which in turn would lead to lost MSIs.
- Save one level of indentation in fire_setup_intr().
- Correct a bug in fire_teardown_intr() which prevented it from
correctly restoring the MSI in the resource, causing allocation of
a resource representing an MSI to fail after the first pass when
repeatedly loading and unloading a driver module.
work.
- Sanity check the parameters passed to the implementations of the
pcib_{read,write}_config() methods. Using illegal values can cause
no real harm but it doesn't hurt to avoid unnecessary data error
traps requiring to flush and re-enable the level 1 caches.
the Sun Fire V215/V245 and Sun Ultra 25/45 machines. This driver also
already includes all the code to support the `Oberon' Uranus to PCIe
bridges found in the Fujitsu-Siemens based Mx000 machines but due to
lack of access to such a system for testing, probing of these bridges
is currently disabled.
Unfortunately, the event queue mechanism of these bridges for MSIs/
MSI-Xs matches our current MD and MI interrupt frameworks like square
pegs fit into round holes so for now we are generous and use one event
queue per MSI, which limits us to 35 MSIs/MSI-Xs per Host-PCIe-bridge
(we use one event queue for the PCIe error messages). This seems
tolerable as long as most devices just use one MSI/MSI-X anyway.
Adding knowledge about MSIs/MSI-Xs to the MD interrupt code should
allow us to decouple the 1:1 mapping at the cost of no longer being
able to bind MSIs/MSI-Xs to specific CPUs as we currently have no
reliable way to quiesce a device during the transition of its MSIs/
MSI-Xs to another event queue. This would still require the problem
of interrupt storms generated by devices which have no one-shot
behavior or can't/don't mask interrupts while the filter/handler is
executed (like the older PCIe NICs supported by bge(4)) to be solved
though.
Committed from: 26C3
so requests may bubble up to a host-PCI bridge driver.
- Distinguish between PCI and PCIe bridges in the device description
so it's a bit easier to follow what hangs off of what in the dmesg.
Unfortunately we can't also tell PCI and PCI-X apart based on the
information provided in the OFW device tree.
- Add quirk handling for the ALi M5249 found in Fire-based machines
which are used as a PCIe-PCIe bridge there. These are obviously
subtractive decoding as as they have a PCI-ISA bridge on their
secondary side (and likewise don't include the ISA I/O range in
their bridge decode) but don't indicate this via the class code.
Given that this quirk isn't likely to apply to all ALi M5249 and
I have no datasheet for these chips so I could implement a check
using the chip specific bits enabling subtractive decoding this
quirk handling is added to the MD code rather than the MI one.
enable IDE I/O" bit which prevents data access traps with revision
0xc8 in Fire-based machines when pci(4) enables PCIM_CMD_PORTEN.
- Like for sun4v also don't add the PCI side of host-PCIe bridges to
the bus on sun4u as they don't have configuration space implement
there either.
is that the JBus to EBus bridges share the interrupt controller of a
sibling JBus to PCIe bridge (at least as far as the OFW device tree
is concerned, in reality they are part of the same chip) so we have to
probe and attach the latter first. That happens to be also the case
due to the fact that the JBus to PCIe bridges appear first in the OFW
device tree but it doesn't hurt to ensure the right order.
OFW device tree for PCI bridges and add a new one for PCI Express.
While at it, take advantage of the former for the rman(9) work-
around in jbusppm(4).
- Failing to register as interrupt controller during attach shouldn't
be fatal so just inform about this instead of panicing.
- Disable rerun of the streaming cache as workaround for a silicon bug
of certain Psycho versions.
- Remove the comment regarding lack of newbus'ified bus_dma(9) as being
able to associate a DMA tag with a device would allow to implement
CDMA flushing/syncing in bus_dmamap_sync(9) but that would totally
kill performance. Given that for devices not behind a PCI-PCI bridge
the host-to-PCI bridges also only do CDMA flushing/syncing based on
interrupts there's no additional disadvantage for polling(4) callbacks
in the case schizo(4) has to do the CDMA flushing/syncing but rather a
general problem.
- Don't panic if the power failure, power management or over-temperature
interrupts doesn't exist as these aren't mandatory and not available
with all controllers (not even Psychos). [1]
- Take advantage of KOBJMETHOD_END.
- Remove some redundant variables.
- Add missing const.
PR: 131371 [1]
- Hook up the streaming buffer (not used by iommu(4) by default, yet)
if available and usable. [1]
- Move the message regarding belated registration as interrupt control
under bootverbose as this isn't something the user should worry about.
Tested by: Michael Moll [1]
be fatal so just inform about this instead of panicing.
- Ensure we use the right softc in case the interrupt of a child is
is routed to the companion PBM instead. This hasn't been seen in the
wild so far but given that it's the case for the Schizo interrupts,
handling this situation also for child interrupts as a precaution
seemed a good idea.
- Deal with broken firmware versions which miss child entries in the
ino-bitmap as seen on V880 by belatedly registering as interrupt
controller in schizo_setup_intr(). [1]
- Add missing '\n' when printing the warning regarding Schizo Errata
I-13.
Reported and tested by: Beat Gaetzi [1]
the code for parsing interrupt maps) to PowerPC and reflect their new MI
status by moving them to the shared dev/ofw directory.
This commit also modifies the OFW PCI enumeration procedure on PowerPC to
allow the bus to find non-firmware-enumerated devices that Apple likes to add,
and adds some useful Open Firmware properties (compat and name) to the pnpinfo
string of children on OFW SBus, EBus, PCI, and MacIO links. Because of the
change to PCI enumeration on PowerPC, X has started working again on PPC
machines with Grackle hostbridges.
Reviewed by: marius
Obtained from: sparc64
and XMITS has to be basically done in the same manner as for
the Sabres, i.e. only for devices behind PCI-PCI-bridges and
after a PIO read on the far side of the farest PCI-PCI-bridge.
Given that the Tomatillo documentation mentions no difference
to the Schizo bridges in this regard and this is also still
part of the procedure described Schizo documentation this
seems about right so adjust accordingly (the unconditional
CDMA flushing/syncing previously done was based on how Linux
behaves).
- Implement CDMA flushing/syncing for Schizo version >= 5,
which requires the workaround described in Schizo Errata I-23.
According to Schizo Errata I-13 it's just unusable with
version < 5 though. [1]
- Don't register the Schizo streaming buffer for now until it's
usage is sorted out according to the erratas.
- Register our interrupt filters with the revived INTR_FAST so
they these interrupts can even interrupt filters of device
drivers as necessary.
- Remove the comment regarding lack of newbus'ified bus_dma(9)
as being able to associate a DMA tag with a device would
allow to implement CDMA flushing/syncing in bus_dmamap_sync(9)
but that would totally kill performance. Given that for devices
not behind a PCI-PCI bridge the host-to-PCI bridges also only
do CDMA flushing/syncing based on interrupts there's no
additional disadvantage for polling(4) callbacks in the case
schizo(4) has to do the CDMA flushing/syncing but rather a
general problem.
Reported by: Michael Moll [1]
while doing the block store workaround so we restore the correct
floating-point registers state in case of nested floating-point
operations resulting from nested interrupts. This allows the
VIS-based block copy/zero functions to be used on machines
requiring this workaround. Alternatively, we could take care of
saving the floating-point registers here, which would be more
inefficiently though and also involves turning off interrupts.
- It turns out that the SCZ_PCI_DMA_SYNC register doesn't work
like the TOMXMS_PCI_DMA_SYNC_PEND one (but more like the
corresponding register in of Hummingbird and Sabre bridges)
and writing the INO of the respective device to it causes a
Safari bus error. However, due to the Schizo errata I-23,
SCZ_PCI_DMA_SYNC can't be used as intended either, so remove
consistent DMA syncing for Schzio bridges for now, which means
that add-on cards with non-"sun4u compliant" (whatever that
means exactly) PCI-PCI-bridges should be avoided until the
proper workaround is implemented. [1]
Reported by: Michael Moll [1]
JBus to PCI 2.2 bridges. In theory, this driver should also handle
`XMITS' Fireplane/Safari to PCI-X bridges but due to lack of access
to such hardware, support for these hasn't be fleshed out, yet.
could trigger an error interrupt that we can't actually to do anything
against as soon as enabling the error handlers.
While at it don't bother about writing only to the write-one-to-clear
bits when clearing error bits.
the latency based on the Min_Gnt register so use the algorithm found
in OpenSolaris as they probably know how to interpret the value Sun
puts into these registers (previously, the latency calculated for
66MHz was most likely wrong) and for bridges additionally set up the
secondary latency register. Also set up the bridge control register
the way it's done in OpenSolaris. As the latency register don't apply
to PCI-Express and the bridge control setup wasn't tested on sun4v
(besides most likely not being needed), expand the #ifndef SUN4V
accordingly.
MFC after: 3 days
counter-timer timecounter so the associated SYSCTL nodes don't clash on
machines having multiple U2P and U2S bridges as well as establishing a
clear mapping between these bridges and their timecounter device.
- Don't bother setting up a "nice" name for the IOMMU, just use the name
returned by device_get_nameunit(9), too.
- Fix some minor style(9) bugs.
- Use __FBSDID in counter.c
MFC after: 1 week
infrastructure. Its only consumer ever was sio(4) and thus was
unused on sparc64 since removing the last traces of sio(4) in
sparc64 configuration files in favor for uart(4) over three
years ago. If similar functionality is required again it should
be brought back as an MD intr_pending() which works for all
busses by using for example interrupt controller hooks.
don't send and EOI which works like on amd64/i386 and blocks all
interrupts on the relevant interrupt controller.
o Replace the post_filter and post_inthread hooks registered when
creating the interrupt events with just ic_clear as on sparc64 we
don't need to do any disable->EOI->enable dance to unblock all but
the relevant interrupt while running the filter or handler; just
not clearing the interrupt already has the same effect.
o Merge from amd64/i386:
- Split the intr_table_lock into an sx lock used for most things,
and a spin lock to protect intrcnt_index.
- Add support for binding interrupts to CPUs, including for the
bus_bind_intr(9) interface, a assign_cpu hook and initially
shuffling interrupts arround in a round-robin fashion.
Reviewed by: jhb
MFC after: 1 month
have separate configuration spaces so by definition they implement
different PCI domains. Thus change psycho(4) to use PCI domains
instead of reenumerating all PCI busses so they have globally unique
bus numbers and drop support for reenumerating busses in the OFW PCI
code.
According to CVS history reenumeration was also required in order to
get some E450 to boot but given that no other open source kernel
changes the PCI bus numbers assigned by the firmware I believe the
real problem was that the old code used the bus number as the device
number for the PCI busses and unlike most of the other machines the
firmwares of the problematic ones don't use disjoint PCI bus numbers
across the host-PCI-bridges.
MFC after: 1 month
for that argument. This will allow DDB to detect the broad category of
reason why the debugger has been entered, which it can use for the
purposes of deciding which DDB script to run.
Assign approximate why values to all current consumers of the
kdb_enter() interface.
is required by the X.Org PCI domains code and additionally needs
a workaround for Hummingbird and Sabre bridges as these don't
allow their config headers to be read at any width, which is an
unusual behavior.
- In psycho(4) take advantage of DEFINE_CLASS_0 and use more
appropriate types for some softc members.
MFC after: 3 days
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)
33MHz for calculating the latency timer values for its children.
Inspired by NetBSD doing the same and Linux as well as OpenSolaris
using a similar approach.
While at it rename a variable and change its type to be more
appropriate fuer values of PCI properties so the variable can be
more easily reused.
- Initialize the cache line size register of PCI devices to a
legal value; the cache line size is limited to 64 bytes by the
Fireplane/Safari, JBus and UPA interconnection busses. Setting
it to an unsupported value caused bad performance at least with
GEM as it causes them to not do cache line bursts and to not
issue cache line commands on the PCI bus.
Approved by: re (kensmith)
MFC after: 1 week
with the INTR_FILTER-enabled MI code. Basically this consists of
registering an interrupt controller (of which there can be multiple
and optionally different ones either per host-to-foo bridge or shared
amongst host-to-foo bridges in any one machine) along with an interrupt
vector as specific argument for all the interrupt vectors used by a
given host-to-foo bridge (roughly similar to registering interrupt
sources on amd64 and i386), providing functions to enable, clear and
disable the interrupts of the children beneath the bridge.
This also includes:
- No longer entering a critical section in tl0_intr() and tl1_intr()
for executing interrupt handlers but rather let the handlers enter
it themselves so in the case of intr_event_handle() we don't enter
a nested critical section.
- Adding infrastructure for binding delivery of interrupt vectors to
specific CPUs which later on can be interfaced with the code from
amd64/i386 for binding interrupts to specific CPUs.
- Getting rid of the wrapper hack introduced along the lines of the
API changes for INTR_FILTER which as a side-effect caused interrupts
associated with ithread handlers only to get the elevated priority
of those associated with filters ("fast handlers") (this removes the
hack also in the non-INTR_FILTER case).
- Disabling (by not clearing) an interrupt in the interrupt controller
until all associated handlers have been executed, which is crucial
for the typical locking strategy of NIC drivers in order to work
correctly in case of shared interrupts. This was a more or less
theoretical problem on sparc64 though, as shared interrupts are
rather uncommon there except for the on-board SCCs and UARTs.
Note that due to the behavior of at least of some of the interrupt
controllers used on sparc64 an enable+EOI instead of a disable+EOI
approach (as implied by the INTR_FILTER MI code and implemented on
other architectures) is used as the latter can cause lost interrupts
or in the worst case interrupt starvation.
o Correct a typo in sbus_alloc_resource() which caused (pass-through)
allocations to only work down to the grandchildren of the bus, which
wasn't a real problem so far as we don't support any devices which are
great-grandchildren or greater of a U2S bridge, yet.
o In fhc(4) use bus_{read,write}_4() instead of bus_space_{read,write}_4()
in order to get rid of sc_bh and sc_bt in the fhc_softc. Also get rid
of some other unneeded members in fhc_softc.
Reviewed by: marcel (earlier version)
Approved by: re (kensmith)
instead of per IOMMU, so we no longer need to program all of them
identically in systems having multiple IOMMUs. This continues the
rototilling of the nexus(4) done about 5 months ago, which amongst
others changed nexus(4) and the drivers for host-to-foo bridges
to provide bus_get_dma_tag methods, allowing to handle DMA tags in
a hierarchical way and to link them with devices.
This still doesn't move the silicon bug workarounds for Sabre (and
in the uncommitted schizo(4) for Tomatillo) bridges into special
bus_dma_tag_create() and bus_dmamap_sync() methods though, as w/o
fully newbus'ified bus_dma_tag_create() and bus_dma_tag_destroy()
this still requires too much hackery, i.e. per-child parent DMA
tags in the parent driver.
- Let the host-to-foo drivers supply the maximum physical address
of the IOMMU accompanying the bridges. Previously iommu(4) hard-
coded an upper limit of 16GB, which actually only applies to the
IOMMUs of the Hummingbird and Sabre bridges. The Psycho variants
as well as the U2S in fact can can translate to up to 2TB, i.e.
translate to 41-bit physical addresses. According to the recently
available Tomatillo documentation these bridges even translate to
43-bit physical addresses and hints at the Schizo bridges doing
43 bits as well.
This fixes the issue the FreeBSD 6.0 todo list item "Max RAM on
sparc64" was refering to and pretty much obsoletes the lack of
support for bounce buffers on sparc64.
Thanks to Nathan Whitehorn for pointing me at the Tomatillo manual.
Approved by: re (kensmith)
allowing the driver for the host-PCI-bridge to indicate that
reenumeration of the PCI busses isn't supported by returning
-1 instead of a valid PCI bus number. This is needed in order
support both Tomatillo, which don't support reenumeration and
thus are apparently intended to be used for independently
numbered PCI domains only, and Psycho bridges, whose busses
need to be reenumerated on at least some E450, without the
#ifndef currently used for sun4v in order to support multiple
independently PCI domains. The actual allocation/incrementation
of the PCI bus numbers is now done in psycho(4), though it
no longer establish a mapping between bus numbers and device
nodes like ofw_pci_alloc_busno() did as that functionality
wasn't used (but can easily brought back if really needed).
The now no longer used sys/sparc64/pci/ofw_pci.c is also
removed from sys/conf/files.sun4v as ofw_pci_alloc_busno()
wasn't used there in the first place.
- In ofw_pci_default_{adjust_busrange,intr_pending}() sanity
check that the device has a parent before passing it on.
- Make psycho_softcs static to sys/sparc64/pci/psycho.c as
it's not used outside of that module.
- In sys/sparc64/pci/ofw_pcib_subr.c remove the superfluous
inclusion of opt_global.h and correct the debug output for
adjusting the subordinate bus number.
instead of using the PCI bus number, like it's already done for
sun4v in order to deal properly with independently numbered PCI
domains which can't be reenumerated (in the case of sun4u f.e.
Tomatillo bridges). For machines where we need to reenumerate
all PCI busses this change obviously introduces the theoretical
cosmetic problem that the device number of the PCI bus no longer
equals to its PCI bus number. In practice this doesn't happen
as both are assigned linearly and in parallel.
allowing it to be a filter/"fast" handler. Locking the interrupt
handlers with a spin lock is mainly a requirement in schizo(4)
but as we ought to register the spin lock anyway it should not
hurt to take advantage of it in psycho(4).
- Pass both a driver_filter_t and a driver_intr_t argument to
psycho_set_intr(), allowing to get rid of the FAST interrupt
flag hack.
- Don't register the over-temperature interrupt handler as filter/
"fast" handler so shutdown_nice() can acquire the process lock.
- Use bus_{read,write}_8() instead of bus_space_{read,write}_8()
in order to get rid of sc_bushandle and sc_bustag in the softc.
- Correct the debug output for adjusting the subordinate bus number.
- Remove the banal and outdated above psycho_filter_stub().
- Fix some white space nits.
iommureg.h (which already began to bitrot) and iommuvar.h from the
sun4v source and adjust some of the source which is shared between
sparc64 and sun4v as appropriate.
sun4v nexus(4) in turn is based on):
o Change nexus(4) to manage the resources of its children so the
respective device drivers don't need to figure them out of OFW
themselves.
o Change nexus(4) to provide the ofw_bus KOBJ interface instead of
using IVARs for supplying the OFW node and the subset of standard
properties of its children. Together with the previous change this
also allows to fully take advantage of newbus in that drivers like
fhc(4), which attach on multiple parent busses, no longer require
different bus front-ends as obtaining the OFW node and properties
as well as resource allocation works the same for all supported
busses. As such this change also is part 4/4 of allowing creator(4)
to work in USIII-based machines as it allows this driver to attach
on both nexus(4) and upa(4). On the other hand removing these IVARs
breaks API compatibility with the powerpc nexus(4) but which isn't
that bad as a) sparc64 currently doesn't share any device driver
hanging off of nexus(4) with powerpc and b) they were no longer
compatible regarding OFW-related extensions at the pci(4) level
since quite some time.
o Provide bus_get_dma_tag methods in nexus(4) and its children in
order to handle DMA tags in a hierarchical way and get rid of the
sparc64_root_dma_tag kludge. Together with the previous two items
this changes also allows to completely get rid of the nexus(4)
IVAR interface. It also includes:
- pushing the constraints previously specified by the nexus_dmatag
down into the DMA tags of psycho(4) and sbus(4) as it's their
IOMMUs which induce these restrictions (and nothing at the
nexus(4) or anything that would warrant specifying them there),
- fixing some obviously wrong constraints of the psycho(4) and
sbus(4) DMA tags, which happened to not actually be used with
the sparc64_root_dma_tag kludge in place and therefore didn't
cause problems so far,
- replacing magic constants for constraints with macros as far
as it is obvious as to where they come from.
This doesn't include taking advantage of the newbus way to get
the parent DMA tags implemented by this change in order to divorce
the IOTSBs of the PCI and SBus IOMMUs or for implementing the
workaround for the DMA sync bug in Sabre (and Tomatillo) bridges,
yet, though.
o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus
by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied
from ofw_upa.h) and renaming its content, which actually applies to
all of Fireplane/Safari, JBus and UPA (in the host bus case), as
appropriate.
o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for
allocating the device info for the children of nexus(4). This is
done in order to not need to export M_NEXUS when deriving drivers
for subordinate busses from the nexus(4) class.
o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so
we can derive subclasses from it.
o Const'ify the nexus_excl_name and nexus_excl_type arrays as well
as add 'associations' and 'rsc', which are pseudo-devices without
resources and therefore of no real interest for nexus(4), to the
former.
o Let the nexus(4) device memory rman manage the entire 64-bit address
space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as
Fireplane/Safari- and JBus-based machines use multiple ranges,
which can't be as easily divided as in the case of UPA (limiting
the address space only served for sanity checking anyway).
o Use M_WAITOK instead of M_NOWAIT when allocating the device info
for children of nexus(4) in order to give one less opportunity
for adding devices to nexus(4) to fail.
o While adapting the drivers affected by the above nexus(4) changes,
change them to take advantage of rman_get_rid() instead of caching
the RIDs assigned to allocated resources, now that the RIDs of
resources are correctly set.
o In iommu(4) and nexus(4) replace hard-coded functions names, which
actually became outdated in several places, in panic strings and
status massages with __func__. [1]
o Use driver_filter_t in prototypes where appropriate.
o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and
sbus(4) as I changed considerable amounts of these drivers as well
as added a bunch of new features, workarounds for silicon bugs etc.
o Fix some white space nits.
Due to lack of access to Exx00 hardware, these changes, i.e. central(4)
and fhc(4), couldn't be runtime tested on such a machine. Exx00 are
currently reported to panic before trying to attach nexus(4) anyway
though.
PR: 76052 [1]
Approved by: re (kensmith)
and friends along with all hacks required to implement them. None of
the drivers currently built (as part of GENERIC, LINT or modules) on
sparc64 or sun4v and none of those we might want to use there in
future uses them, AFAICT there actually never was a driver hooked up
to the sparc64 or sun4v build that correctly used these functions
(and it looks like that due to a bug read{b,w,l}()/write{b,w,l}() and
the other functions working on a memory handle never actually worked on
sun4v). All they ever were good for on sparc64 and sun4v was erroneously
dragging in dependencies on isa(4) in drivers like f.e. dpt(4), si(4)
and syscons(4) in source files that supposedly were bus-neutral and
hiding issues with drivers like f.e. ng_bt3c(4) that used these
functions with busses other than isa(4) and therefore couldn't work on
these platforms.
- Clear the PCI AFSR and status error bits as previous errors still
might be indicated.
- Set up the PCI control and diagnostic registers according to the
capabilities, workarounds, etc of/for specific revisions of the
supported bridges. This includes no longer setting Hummingbird-/
Sabre-specific bits in the PCI control register but preserving
what the firmware has initialized them to like OpenSolaris does.
Previously we were setting these bits according to the example in
the Sabre documentation, which I doubt is appropriate for all
Sabre based designs and especially not for Hummingbirds. This
also includes not enabling bus parking unless the firmware tells
us to.
- Set the PCI latency timer register as this isn't always done by
the firmware.
o Remove a redundant argument from psycho_set_intr() and in this
function check the return value of bus_setup_intr(). [2]
o Let psycho_setup_intr() return ENOMEM instead of 0 when it can't
allocate memory for the interrupt wrapper stub and EINVAL instead
of 0 if it can't find the interrupt vector in the interrupt map.
o Add a workaround for a bug of the Sabre-APB-combination where it
doesn't drain DMA write data for devices behind additional PCI-PCI
bridges underneath the APB PCI-PCI bridge. This workaround (do
things necessary in order to achieve a manual drain when coherency
is required) is currently implemented in psycho_setup_intr() and
psycho_intr_stub() (for easy MFC'ing) and therefore is only applied
for interrupt handlers. This should be moved to psycho(4)-specific
bus_dma_tag_create() and bus_dmamap_sync() methods, respectively,
once this driver is converted to make use of BUS_GET_DMA_TAG(), so
the workaround is also applied for polling(4) callbacks. [3]
o Fix some minor style issues.
Info from: OpenSolaris [1]
Info from: Linux, OpenBSD, OpenSolaris [3]
Suggested by: Coverity Prevent (CID 682) [2]
MFC after: 1 month
firmware (mainly 'pmu' and its 'lomp' dupe found in a couple of
later USII{e,i}-based machines) by checking whether a device with
the same triple of bus number, slot and function already has been
added. This is the simple yet effective approach introduced in
OpenBSD some time ago, but which has the flaw that it assumes
that the device and its dupe(s) found in the OFW device tree are
equal or at least the one encountered first is in some way the
more important one (this is the case with 'pmu' and 'lomp'; the
'pmu' node has couple of properties and children while the 'lomp'
one misses most of these). If there's ever a device/dupe pair
where we don't encounter the more important node first, we'll
probably need to introduce a quirk list in order to add the
desired device but prevent its dupe(s) from being added.
MFC after: 1 week
and resume methods so these events propagate through the device driver
hierarchy.
- In dma(4) enable the chaining of the DMA engine interrupt handler for
the LANCE devices via a dma_setup_intr(). This was commented out before
as I was unsure whether I'd use it but this is probably cleaner than
fiddling with the DMA engine interrupt in the LANCE driver directly.
- In ebus_setup_dinfo() free 'intrs' instead of 'reg' twice in case
setting up a child fails due to routing one of its interrupts fails. [1]
Found by: Coverity Prevent [1]
MFC after: 3 days
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.
to search for a specific extended capability. If the specified capability
is found for the given device, then the function returns success and
optionally returns the offset of that capability. If the capability is
not found, the function returns an error.
from sys/sparc64/include/ofw_upa.h to sys/sparc64/pci/ofw_pci.h and
rename them to struct ofw_pci_ranges and OFW_PCI_RANGE_* respectively.
This ranges struct only applies to host-PCI bridges but no to other
bridges found on UPA. At the same time it applies to all host-PCI
bridges regardless of whether the interconnection bus is Fireplane/
Safari, JBus or UPA.
- While here rename the PCI_CS_* macros in sys/sparc64/pci/ofw_pci.h
to OFW_PCI_CS_* in order to be consistent and change this header to
use uintXX_t instead of u_intXX_t.
the bridge (PCI bus A or B) we are attaching to rather than registering
both handlers at once when attaching to the first half we encounter.
This is a bit cleaner as it corresponds to which PCI bus error interrupt
actually is assigned to the respective half by the OFW and allows to
collapse both PCI bus error interrupt handlers into one function easily.
- Use the actual RID of the respective interrupt resource as index into
sc_irq_res and also use it when allocating the resource. For now this
is a bit cleaner and will be mandatory later on.
- According to OpenSolaris the spare hardware interrupt is used as the
over-temperature interrupt in systems with Psycho bridges. Unlike as
with the SBus-based workstations I didn't manage to trigger it when
covering the fan outlets of an U60 but better be safe than sorry and
register a handler anyway.
MFC after: 1 month
bug by explaining what the problem is and how the workaround works.
- Fix some cosmetics nits, mainly properly terminate sentences in comments,
which I missed when backporting the style changes to psycho(4) in psycho.c
rev. 1.54 due to lack of corresponding code.
- The "USIIe version of the Sabre bridge" actually is termed "Hummingbird";
name it as such in comments and messages.
INO) for incorrect interrupt map entries on E250 machines. These
incorrect entries caused the INO of the on-board HME to be also
assigned to the second on-board NS16550 and to the on-board printer
port controller. Further down the road caused hme(4) to fail to attach
to the on-board HME in FreeBSD 5 and 6 as INTR_FAST and non-INTR_FAST
handlers can't share the same IRQ there (it's unknown what whould
happen in -CURRENT now that INTR_FAST and non-INTR_FAST handlers can
share an IRQ but I'd expect funny problems with uart(4)).
- Make sure there are exactly 4 PCI ranges instead of just checking
that the bridge has a 'ranges' property in the OFW device tree at all.
Besides the fact that currently the 64bit memory range isn't used by
this driver it we can't really work with less than 4 ranges and don't
have memory for more than 4 bus handles for the ranges in the softc.
- Remove sc_range and sc_nrange from softc; for the bridges supported
by this driver we no longer need to know the ranges besides the bus
handles obtained from them once this driver is attached. That way we
also can free the memory allocated for sc_range during attach again.
- Remove sc_dvmabase from the softc and pass it to psycho_iommu_init()
via an additional argument as we no longer need to know the DVMA base
in this driver once the IOMMU is initialized.
- Remove sc_dmatag from the softc, there isn't much sense in keeping
the nexus dma tag around locally.
PR: 88279 [1]
Info from: OpenSolaris [1]
Tested by: kensmith [1]
MFC after: 1 month
between this driver and other Host-PCI bridge drivers based on this one:
- Make the code fit into 80 columns.
- Make the code adhere style(9) (don't use function calls in initializers,
use uintXX_t instead of u_intXX_t, add missing prototypes, ...).
- Remove unused and superfluous struct declaration, softc member, casts,
includes, etc.
- Use FBSDID.
- Sprinkle const.
- Try to make comments and messages consistent in style throughout the
driver.
- Use convenience macros for the number of interrupts and ranges of the
bridge.
- Use __func__ instead of hardcoded function names in panic strings and
error messages. Some of the hardcoded function names actually were
outdated through moving code around. [1]
- Rename softc members related to the PCI side of the bridge to sc_pci_*
in order to make it clear which side of the bridge they refer to (so
stuff like sc_bushandle vs. sc_bh is less confusing while reading the
code).
PR: 76052 [1]
ofw_bus_gen_get_*() for providing the ofw_bus KOBJ interface in order
to reduce code duplication.
- While here sync the various sparc64 bus drivers a bit (handle failure
to attach a child gracefully instead of panicing, move the printing
of child resources common to bus_print_child() and bus_probe_nomatch()
implementations of a bus into a <bus>_print_res() function, ...) and
fix some minor bugs and nits (plug memory leaks present when attaching
a bus or child device fails, remove unused struct members, ...).
Additional testing by: kris (central(4) and fhc(4))
bridge in the device tree which lacks the mandatory (also by the OFW PCI
bus binding spec) "reg" property. Change the code to just ignore nodes
missing the "reg" property instead of panicing when encountering such a
node. Also ignore nodes without a "name" property (guaranteed by the OFW
PCI bus binding spec). This brings the behaviour of the MD OFW PCI code
regarding such incomplete nodes in line with the EBus and the SBus code.
Tested by: Cyril Tikhomiroff <tikho@anor.net>
MFC after: 1 month
