Age | Commit message (Collapse) | Author |
|
hubs are known during autoconf. Then, pick the most populated 2GB window
as our DMA memory window. xbridge(4) can thus program the correct settings
regardless of the order in which the xbow(4) attach.
|
|
Remember the hub widget number of each node, instead of only the master node.
Use this in xbridge to compute the proper direct DMA map configuration
register value (it needs to embed the hub widget number matching the
physical address range).
This should allow us to pick memory from a different node than the one
we booted from, as the DMA window, if wanted.
|
|
at physical address zero onwards, but instead assume it is controlled by
the dma_constraints range.
This will eventually allow a different window to be selected.
|
|
|
|
given pcitag_t configuration address space. Currently, all pci controllers
will return the usual 0x100 bytes of PCI configuration space, but this will
eventually change on PCIe-capable controlers.
ok kettenis@
|
|
|
|
ok krw@ kettenis@
|
|
hierarchy. Everything attached to a single root node anyway, so at
best we had a bush.
"i think it is good" deraadt@
|
|
the pci write buffers.
|
|
bridge interrupts dance when trying to access an uninplemented ioc3 register.
Makes PIC handling simpler as a bonus.
|
|
on the bus, to workaround timeout problems, according to IRIX knowledge which
made its way to Linux.
|
|
like it is everything.h
ok tedu
|
|
tested by marco@
|
|
and compare against them when attaching potential console drivers, to figure
out whether they indeed are acting are console devices or not.
|
|
instead of duplicating tedious mask and shift constructs MAXINT times.
|
|
ok kettenis, sgi usage of rbus_new_body() pointed out by miod
|
|
being set to zero; this allows a full PIC bus to correctly configure I/O
resources.
While there, when initializing a ppb, setup I/O resources before memory
resources; without this a ppb connected to a PIC could not get I/O resources
if devices behind it would use both I/O and memory resources.
|
|
|
|
|
|
otherwise backing store may not get allocated for it;
"go ahead" kettenis@
|
|
before attaching wsdisplay; it was turning out harmless but using more
cpu time for nothing than necessary.
ok deraadt@
|
|
|
|
Octane systems, as well as some Onyxes. With special permission to change a
systemwide .h file and add a manpage from deraadt@
Magic numbers and operation sequencing borrowed from Linux; tested on
Octane + ESI.
ok deraadt@
|
|
this gives us working glass console on Fuel, as well as on Octane systems
with Odyssey graphics.
Joint work with jsing@
|
|
number the PCI bus they are on is connected to. Will be used shortly to help
the console device selection logic.
|
|
|
|
card, which can be found in Octane, Octane2, Fuel, Tezro and Onyx systems.
ok miod@
|
|
errors at the widget level). Extremely crude for now.
|
|
when invoking the cache functions. The physical address is needed when
operating on physically-indexed caches, such as the L2 cache on Loongson
processors.
Preprocessor abuse makes sure that the physical address computation gets
compiled out when running on a kernel compiled for virtually-indexed
caches only, such as the sgi kernel.
|
|
It prevents deadlock with TLB shootdown and clock interrupt.
ok miod@
|
|
Also few xheart modification for SMP.
ok miod@
|
|
struct intrhand, instead of having it malloc()'ed.
|
|
to be aligned on a 2GB boundary. Therefore the `add 512MB' bit used on
Octane does not give us a 0.5GB-2.5GB usable DMA range, but a 0.5GB-2GB
range; trying to use address in the 2GB-2.5GB range would cause PCI
DMA errors at the xbridge level.
There is no real benefit in using it, since this required us to keep
subtracting or adding 0.5GB when converting DMA address to physical
memory address or the other way around.
So stop using it; this makes a few parts of the code simpler (and until
bounce buffers are implemented, Octane systems will not use more than
1.5GB of memory).
|
|
update #include needs. No functional change.
|
|
change.
|
|
superio chip interrupt on two different pins (yet do not advertize
themselves as a multi-function device, of course).
So, on one hand, this makes the ioc attachment code simpler, because it
simply needs to map interrupt pins A and B, and another hand, this moves
all the interrupt knowledge to the PCI bridge driver, since routing of pin
B differs whether the device is the onboard IOC3 chip (and able to use
any of the 8 bridge interrupt sources...) or on a PCI board (with pin
mapping sane, since controlled by the bridge).
This makes superio interrupts on CADduo boards work. Tested to cause
no regressions on Origin 200, Octane and Fuel.
|
|
for IP35 systems with IOC3 onboard Ethernet to get their Ethernet address
since it's no longer stored as an owmac(4) device on the IOC3 device itself.
|
|
TGT_ORIGIN, which enables support for all IP27 and IP35 systems. The original
two options have always been used together, and go back to when pefo thought
supporting multiple nodes would be significant work. Since an Origin 200
can be a dual-node system, making a distinction between single node and
multiple node systems is a moot point anyway.
Be sure to rerun config(8) before rebuilding a kernel.
|
|
system type list (which really is the system family) and a subsystem type.
No functional change yet.
|
|
|
|
to prevent further abuse of it.
|
|
irq we route it to; this makes clear that devices connected to different
xbridges but using the same xbridge irq are actually not shared at all; and
this also helps figure out which device cause spurious interrupts.
|
|
figure out how the interrupt was routed from xbridge to xheart... (it bypasses
the regular `have xbridge send a xio interrupt packet' mechanism)
|
|
instead of embedding that knowledge in xbridge(4); will be used elsewhere
shortly.
|
|
logical IPL level, and per-platform (IP27/IP30/IP32) code will from the
necessary hardware mask registers.
This allows the use of more than one interrupt mask register. Also, the
generic (platform independent) interrupt code shrinks a lot, and the actual
interrupt handler chains and masking information is now per-platform private
data.
Interrupt dispatching is generated from a template; more routines will be
added to the template to reduce platform-specific changes and share as much
code as possible.
Tested on IP27, IP30, IP32 and IP35.
|
|
sources were masked and saved in ci_ipending, as splx() will unmask what needs
to be unmasked anyway. ci_ipending only now needs to store pending soft
interrupts, so rename it to ci_softpending.
|
|
does almost exactly what splx() is doing if ipending is zero, and triggers
soft interrupts as well.
So don't bother checking for ipending in splx, and always invoke pending_int,
which gets renamed as splx_handler for consistency.
|
|
in the coprocessor 0 status register (coupled with ICR on rm7k/rm9k), and
may be completely alien to real hardware interrupt masks, so don't make
things unnecessary confusing.
|
|
one pci bus can attach to an xbridge (if PIC) and both being `bus 0' would
make dmesg confusing.
While there, seize the opportunity of this new dmesg line to display the
bus mode (PCI or PCIX) and speed.
|
|
|