summaryrefslogtreecommitdiffstats
path: root/sys/sparc64
Commit message (Collapse)AuthorAgeFilesLines
* Add uslcom to the build too.thompsa2009-02-151-0/+1
| | | | Reminded by: Michael Butler
* Switch over GENERIC kernels to USB2 by default.thompsa2009-02-151-5/+56
| | | | Tested by: make universe
* Improve r185008 so the streaming cache is only flushed whenmarius2009-02-102-8/+11
| | | | a mapping actually met the threshold.
* - Use the generally more appropriate PROM base rather than themarius2009-02-101-1/+1
| | | | | | | | | kernel one as the non-faulting flush address in the loader so we can can change KERNBASE and VM_MIN_KERNEL_ADDRESS if we ever want to without needing to worry about using a compatible loader. - Correctly check for LOADER_DEBUG. - Add a missing const for page_sizes[].
* - Currently the PMAP code is laid out to let the kernel TSB cover themarius2009-01-013-2/+29
| | | | | | | | | | | whole KVA space using one locked 4MB dTLB entry per GB of physical memory. On Cheetah-class machines only the dt16 can hold locked entries though, which would be completely consumed for the kernel TSB on machines with >= 16GB. Therefore limit the KVA space to use no more than half of the lockable dTLB slots, given that we need them also for other things. - Add sanity checks which ensure that we don't exhaust the (lockable) TLB slots.
* - According to comments in OpenBSD, E{2,4}50 tend to have fragilemarius2008-12-221-28/+12
| | | | | | | | | | | | | | | | | | | | | | | | | firmware versions which wedge when using the OFW test service, so given that we don't really depend on SUNW,stop-self just nuke it altogether instead of risking problems. - At least Fire V880 have a small hardware glitch which causes the reception of IDR_NACKs for CPUs we actually haven't tried to send an IPI to, even not as part of the initial try. According to tests this apparently can be safely ignored though, so just return if checking for the individual IDR_NACKs indicates no outstanding dispatch. Serializing the sending of IPIs between MD and MI code by the combined usage of smp_ipi_mtx makes no difference to this phenomenon. [1] - Provide relevant debugging bits already with the initial panic in case of problems with the IPI dispatch, which would have allowed to diagnose the above problem without a specially built kernel. - In case of cheetah_ipi_selected() base the delay we wait for other CPUs which also might want to dispatch IPIs on the total amount of CPUs instead of just the number of CPUs we let this CPU send IPIs to because in the worst case all CPUs also want to IPI us at the same time. Reported and access for extensive tests provided by: Beat Gaetzi [1]
* Modularize the Open Firmware client interface to allow run-time switchingnwhitehorn2008-12-206-22/+27
| | | | | | | | | | | | of OFW access semantics, in order to allow future support for real-mode OF access and flattened device frees. OF client interface modules are implemented using KOBJ, in a similar way to the PPC PMAP modules. Because we need Open Firmware to be available before mutexes can be used on sparc64, changes are also included to allow KOBJ to be used very early in the boot process by only using the mutex once we know it has been initialized. Reviewed by: marius, grehan
* - Failing to register as interrupt controller during attach shouldn'tmarius2008-12-181-10/+35
| | | | | | | | | | | | | | | | 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]
* Make gpart the default partitioning class on all platforms.marcel2008-12-171-2/+2
| | | | | | | Both ia64 and powerpc were using gpart exclusively already so there's no change for those two. Discussed on: arch@
* AT_DEBUG and AT_BRK were OBE like 10 years ago, so retire them.imp2008-12-171-12/+0
| | | | Reviewed by: peter
* Adapt parts of the sparc64 Open Firmware bus enumeration code (in particular,nwhitehorn2008-12-1513-261/+22
| | | | | | | | | | | | | | | 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
* Remove "[KEEP THIS!]" from COMPAT_43TTY. It's not really that important.ed2008-12-021-1/+1
| | | | | | | Sgtty is a programming interface that has been replaced by termios over the years. In June we already removed <sgtty.h>, which exposes the ioctl()'s that are implemented by this interface. The importance of this flag is overrated right now.
* Switch to ath hal source code. Note this removes the ath_halsam2008-12-011-0/+1
| | | | | | | | | | | | | | | | | module; the ath module now brings in the hal support. Kernel config files are almost backwards compatible; supplying device ath_hal gives you the same chip support that the binary hal did but you must also include options AH_SUPPORT_AR5416 to enable the extended format descriptors used by 11n parts. It is now possible to control the chip support included in a build by specifying exactly which chips are to be supported in the config file; consult ath_hal(4) for information.
* Add sv_flags field to struct sysentvec with intention to provide descriptionkib2008-11-221-1/+2
| | | | | | | | of the ABI of the currently executing image. Change some places to test the flags instead of explicit comparing with address of known sysentvec structures to determine ABI features. Discussed with: dchagin, imp, jhb, peter
* - bump __FreeBSD version to reflect added buf_ring, memory barriers,kmacy2008-11-221-0/+4
| | | | | | | | | | | | | | | | | and ifnet functions - add memory barriers to <machine/atomic.h> - update drivers to only conditionally define their own - add lockless producer / consumer ring buffer - remove ring buffer implementation from cxgb and update its callers - add if_transmit(struct ifnet *ifp, struct mbuf *m) to ifnet to allow drivers to efficiently manage multiple hardware queues (i.e. not serialize all packets through one ifq) - expose if_qflush to allow drivers to flush any driver managed queues This work was supported by Bitgravity Inc. and Chelsio Inc.
* - According to OpenSolaris, CDMA flushing/syncing for Tomatillosmarius2008-11-204-74/+218
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* Use the interrupt level right below PIL_FAST for executing interruptmarius2008-11-192-10/+19
| | | | | | | filters instead of PIL_FAST and allow special filters and handlers for interrupts which need to be able to interrupt even filters, f.e. bus error interrupts, to be registered with the revived INTR_FAST at PIL_FAST.
* - Allow the front-end to specify that iommu(4) should disablemarius2008-11-163-19/+25
| | | | | | | | | rerun of the streaming cache for silicon bug workarounds. - Announce the presence of a streaming cache on attach for informational purposes. - For performance reasons don't do unnecessary flushes of the streaming cache when coherent mappings are synced. - Fix some minor style issues.
* Use the spitfire VIS block copy/zero functions also with cheetah-marius2008-11-161-1/+7
| | | | | | | | | | | | class CPUs. In theory one could also use versions additionally taking advantage of the prefetch cache with cheetah-class CPUs, in my worldstone runs these either didn't provide extra speedup (USIII+) in comparison to the existing spitfire versions or were even slightly slower (USIIIi) though, so they aren't committed for now. The basic problem leading to the VIS-based copy/zero functions being initially disabled for cheetah-class CPUs was solved by letting cheetah_init() clear DCR_IFPOE.
* Micro-optimize spitfire_block_{copy,zero}():marius2008-11-161-9/+4
| | | | | | - Predict the loop as taken as it's more likely that there's still data to copy and memory to zero respectively. - Don't waste the delay slot.
* - Turn off interrupts instead of only entering a critical sectionmarius2008-10-281-14/+10
| | | | | | | | | | | | | | | | | | | | | | 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]
* - In GCC 4.2 __builtin_frame_address() was fixed to include themarius2008-10-272-23/+11
| | | | | | | | | | V9 stack bias so we no longer need to add it in db_backtrace() and stack_capture() respectively. This also reverts r182018, which kludged around the resulting unaligned access. - Sync the sun4v versions of db_trace.c and stack_machdep.c with the sparc64 ones and fix some style bugs. MFC after: 3 days
* Enable mpt(4) as some later models have on-board Fusion-MPTmarius2008-10-111-3/+2
| | | | | | | | controllers and it seems to work just fine with at least an add-on SAS3080X. While at it, remove the commented out ncr(4) as it doesn't even use bus_dma(9), which isn't worth fixing though as sym(4) already supports a superset of the controllers driven by ncr(4).
* Collect N identical (or near identical) mkdumpheader() implementations intopeter2008-10-011-22/+1
| | | | one, as threatened in the comment. Textdump magic can be passed in.
* Add a driver for `Schizo' Fireplane/Safari to PCI 2.1 and `Tomatillo'marius2008-09-283-0/+1649
| | | | | | 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.
* Replace all calls to minor() with dev2unit().ed2008-09-271-2/+2
| | | | | | | | | | | | | | | After I removed all the unit2minor()/minor2unit() calls from the kernel yesterday, I realised calling minor() everywhere is quite confusing. Character devices now only have the ability to store a unit number, not a minor number. Remove the confusion by using dev2unit() everywhere. This commit could also be considered as a bug fix. A lot of drivers call minor(), while they should actually be calling dev2unit(). In -CURRENT this isn't a problem, but it turns out we never had any problem reports related to that issue in the past. I suspect not many people connect more than 256 pieces of the same hardware. Reviewed by: kib
* Change the static struct sysentvec and struct Elf_Brandinfo initializerskib2008-09-241-46/+47
| | | | | | | | | | | to the C99 style. At least, it is easier to read sysent definitions that way, and search for the actual instances of sigcode etc. Explicitely initialize sysentvec.sv_maxssiz that was missed in most sysvecs. No objection from: jhb MFC after: 1 month
* Use the STICK timers only when absolutely necessary, i.e. if a machinemarius2008-09-203-29/+33
| | | | | | | | | | consists of CPUs running at different speeds, for driving hardclock as these timers in turn are driven at frequencies as low as 5MHz, resulting in bad granularity compared to the TICK timers. However, don't employ the workaround for the BlackBird erratum #1 when using the TICK timer on machines with cheetah-class CPUs for performance reasons. Reported by: Florian Smeets
* Clear any possibly pending PCI error bits left by the firmware. Thesemarius2008-09-182-64/+56
| | | | | | | 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.
* - Add a missing prototype.marius2008-09-181-2/+2
| | | | - Remove a banal comment.
* - Newer firmware versions no longer provide SUNW,stop-self so justmarius2008-09-183-30/+58
| | | | | | | | | | disable interrupts and loop forever with these. - Hide all MP-related bits in <machine/smp.h> underneath #ifdef SMP. - Inline ipi_all_but_self(9) and ipi_selected(9). We don't expose any additional bits but save a few cycles by doing so. - Remove ipi_all(9), which actually only called panic(9). It can't be implemented natively anyway and having it removed at least causes MI users to fail already fail when linking.
* Add drivers for the power management devices found on Fireplane/marius2008-09-102-0/+358
| | | | | | Safari- and JBus-based machines. Currently the main purpose of these drivers is debugging of the resource allocation on nexus(4) and the register content of these devices though.
* Work around Cheetah+ erratum 34 (USIII+ erratum #10) by relocatingmarius2008-09-102-22/+115
| | | | | | | | the locked entry in it16 slot 0, which typically is occupied by the PROM, and manually entering locked entries in slots != 0. Thanks to Hubert Feyrer for donating the Blade 2000 this change was developed on.
* For cheetah-class CPUs ensure that the dt512_0 is set to hold 8k pagesmarius2008-09-086-5/+59
| | | | | | | | | | for all three contexts and configure the dt512_1 to hold 4MB pages for them (e.g. for direct mappings). This might allow for additional optimization by using the faulting page sizes provided by AA_DMMU_TAG_ACCESS_EXT for bypassing the page size walker for the dt512 in the superpage support code. Submitted by: nwhitehorn (initial patch)
* USIII and beyond CPUs have stricter requirements when it comesmarius2008-09-086-13/+29
| | | | | | | | | | | | | | | | | | to synchronization needed after stores to internal ASIs in order to make side-effects visible. This mainly requires the MEMBAR #Sync after such stores to be replaced with a FLUSH. We use KERNBASE as the address to FLUSH as it is guaranteed to not trap. Actually, the USII synchronization rules also already require a FLUSH in pretty much all of the cases changed. We're also hitting an additional USIII synchronization rule which requires stores to AA_IMMU_SFSR to be immediately followed by a DONE, FLUSH or RETRY. Doing so triggers a RED state exception though so leave the MEMBAR #Sync. Linux apparently also has gotten away with doing the same for quite some time now, apart from the fact that it's not clear to me why we need to clear the valid bit from the SFSR in the first place. Reviewed by: nwhitehorn
* o Move the MODULE_DEPEND() for cam(4) from the esp_sbus.c front-end tomarius2008-09-083-97/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the ncr53c9x.c core where it actually belongs so future front-ends don't need to add it. o Use the correct OFW property when looking for the initiator ID of the SBus device. o Don't specify an alignment when creating the parent DMA tag for SUNW,fas; their DMA engine doesn't require an alignment constraint and it's no inherited by the child DMA tags anyway (which probably is a bug though). o Drop the superfluous sc_maxsync and use sc_minsync instead. The former apparently was added due to a confusion with the maximum frequency used in cam(4), which basically corresponds to the inverse of minimum sync period. o Merge ncr53c9x.c from NetBSD: 1.116: NCRDMA_SETUP() should be called before NCR_SET_COUNT() and NCRCMD_DMA command in ncr53c9x_select(). 1.125: free allocated resources on detach. o Static'ize ncr53c9x_action(), ncr53c9x_init() and ncr53c9x_reset() as these are not required outside of ncr53c9x.c. o In ncr53c9x_attach() don't leak the device mutex in case attaching fails. o Register an asynchronous notification handler so in case cam(4) reports a lost device we can cancel outstanding commands and restore the default parameters for the target in question. o For FAS366 correctly support 16-bit target IDs and let it know that we use 32-bit transfers. o Overhaul the negotiation of transfer settings. This includes distinguishing between current and goal transfer settings of the target so we can renegotiate their goal settings when necessary and correcting the order in which tagged, wide and synchronous transfers are negotiated. o If we are requesting sense, force a renegotiation if we are currently using anything different from asynchronous at 8 bit as the target might have lost our transfer negotiations. o In case of an XPT_RESET_BUS just directly call ncr53c9x_init() instead of issuing a NCRCMD_RSTSCSI, which in turn will issue an interrupt that is treated as an unexpected SCSI bus reset by ncr53c9x_intr() and thus calls ncr53c9x_init(). Remove the now no longer used ncr53c9x_scsi_reset(). o Correct an off-by-one error when setting cpi->max_lun. o In replace printf(9) with device_printf(9) calls where appropriate and in ncr53c9x_action() remove some unnecessarily verbose messages. o In ncr53c9x_sched() use TAILQ_FOREACH() instead of reimplementing it and consolidate two tagging-related target info checks into one. o In ncr53c9x_done() set the CAM status to CAM_SCSI_STATUS_ERROR when appropriate, respect CAM_DIS_AUTOSENSE and teach it to return SCSI status information. o In ncr53c9x_dequeue() ensure the tags are cleared. o Use ulmin() instead of min() where appropriate. o In ncr53c9x_msgout() consistently use the reset label. o When we're interrupted during a data phase and the DMA engine is still active, don't panic but reset the core and the DMA engine as this should be sufficient. Also, the typical problem for triggering this was the lack of renegotiation when requesting sense. o Correctly handle DEVICE RESETs. o Adapt the locking of esp(4) to MPSAFE cam(4). This includes moving the calls of lsi64854_attach() to the bus front-ends so it can pass the esp(4) mutex to bus_dma_tag_create(9). o Change the LSI64854 driver to not create a DMA tag and map for the Ethernet channel as le(4) will handle these on its own as well as sync and unload the DMA maps for the SCSI and parallel port channel after a DMA transfer. o Cam(4)'ify some NetBSD-centric comments. o Use bus_{read,write}_*(9) instead of bus_space_{read,write}_*(9) and take advantage of rman_get_rid(9) in order to save some softc members. Reviewed by: scottl MFC after: 1 month
* When determining whether we trapped while in the PROM don't onlymarius2008-09-041-0/+4
| | | | check for addresses below the PROM range but also those above.
* Use the PROM provided SUNW,set-trap-table to take over the trapmarius2008-09-043-0/+35
| | | | | | | | | | table. This is required in order to set obp-control-relinquished within the PROM, allowing to safely read the OFW translations node. Without this, f.e. a `ofwdump -ap` triggers a fatal reset error or worse things on machines based on USIII and beyond. In theory this should allow to remove touching %tba in cpu_setregs(), in practice we seem to currently face a chicken and egg problem when doing so however.
* Ensure the caches have the desired configuration (see especiallymarius2008-09-042-0/+2
| | | | cheetah_cache_enable()).
* Flesh out MMU and cache handling of cheetah-class CPUs.marius2008-09-046-7/+171
|
* The physical address space of cheetah-class CPUs has been extendedmarius2008-09-042-5/+17
| | | | | | | | | | to 43 bits so update TD_PA_BITS accordingly. For the most part this increase is transparent to the existing code except for when reading the physical address from ASI_{D,I}TLB_DATA_ACCESS_REG, which we only do in the loader and which was already adjusted in r182478, or from the OFW translations node. While at it, ensure we are only taking valid OFW mapping entries into account.
* Additionally clear the STICK bit in the SOFTINT register whenmarius2008-09-031-1/+1
| | | | | receiving a PIL_TICK interrupt. This change was erroneously omitted in r182730.
* - USIII-based machines can consist of CPUs running at differentmarius2008-09-0313-127/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frequencies (and having different cache sizes) so use the STICK (System TICK) timer, which was introduced due to this and is driven by the same frequency across all CPUs, instead of the TICK timer, whose frequency varies with the CPU clock, to drive hardclock. We try to use the STICK counter with all CPUs that are USIII or beyond, even when not necessary due to identical CPUs, as we can can also avoid the workaround for the BlackBird erratum #1 there. Unfortunately, using the STICK counter currently causes a hang with USIIIi MP machines for reasons unknown, so we still use the TICK timer there (which is okay as they can only consist of identical CPUs). - Given that we only (try to) synchronize the (S)TICK timers of APs with the BSP during startup, we could end up spinning forever in DELAY(9) if that function is migrated to another CPU while we're spinning due to clock drift afterwards, so pin to the CPU in order to avoid migration. Unfortunately, pinning doesn't work at the point DELAY(9) is required by the low-level console drivers, yet, so switch to a function pointer, which is updated accordingly, for implementing DELAY(9). For USIII and beyond, this would also allow to easily use the STICK counter instead of the TICK one here, there's no benefit in doing so however. While at it, use cpu_spinwait(9) for spinning in the delay- functions. This currently is a NOP though. - Don't set the TICK timer of the BSP to 0 during at startup as there's no need to do so. - Implement cpu_est_clockrate(). - Unfortunately, USIIIi-based machines don't provide a timecounter device besides the STICK and TICK counters (well, in theory the Tomatillo bridges have a performance counter that can be (ab)used as timecounter by configuring it to count bus cycles, though unlike the performance counter of Schizo bridges, the Tomatillo one is broken and counts Sun knows what in this mode). This means that we've to use a (S)TICK counter for timecounting, which has the old problem of not being in sync across CPUs, so provide an additional timecounter function which binds itself to the BSP but has an adequate low priority.
* ahc(4) work better in Sparc64 with AHC_ALLOW_MEMIO.obrien2008-09-021-0/+1
| | | | Submitted by: Nathan Whitehorn <nwhitehorn@freebsd.org>
* - USIII-based machines can consist of CPUs having different cachemarius2008-09-029-67/+85
| | | | | | | | sizes (and running at different frequencies) so move the cacheinfo to the PCPU data. While at it, remove some redundant and/or unused members from struct cacheinfo. - In sparc64_init don't assume the first CPU node we find in the OFW device tree is the BSP.
* Bypass isa_probe_children(9) and directly call bus_generic_attach(9)marius2008-09-021-1/+7
| | | | | | | | | | | | in order to avoid the invasive probes done by identify-routines of ISA drivers, which may access unassigned addresses or those of unrelated devices and thus in turn can trigger master/target aborts as revealed by r182108 and ahc(4). I think that this is also the cause of the hang previously seen on B100 blades during boot. Bypassing isa_probe_children(9) also avoids adding ISA hints, which just can be wrong for sparc64. Reported by: gavin
* There's a race in kmem(4) between checking whether a page is residentmarius2008-08-241-0/+14
| | | | | | | | | in the kernel and copying it out, causing a panic when faulting on a nofault entry. Handle this case gracefully by letting the kernel copy functions return EFAULT instead. As such this change addresses the same problem as r154721 does for i386. MFC after: 3 days
* MFamd64: r133413marius2008-08-241-9/+6
| | | | | | | | | | In syscall, always make a copy of parameters from trapframe, this becauses some syscalls using set_mcontext can sneakily change parameters and later when those syscalls references parameters, they will wrongly use register values in mcontext_t. PR: 72998 MFC after: 3 days
* Announce the speed of the PCI bus for informational purpose.marius2008-08-241-3/+6
| | | | MFC after: 3 days
* The PCI specifications don't explain the details on how to calculatemarius2008-08-241-20/+58
| | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud