| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
|
|
|
|
and add comments explaining why it's very unlikely we'll ever see TIO
widgets on mips-based SGI systems (unless someone builds a Mengele-style
XIO link).
|
|
widget; make sure we reserve its address span so that no device risks
having its resources overlap the PROM.
|
|
running on, and report this both as the hw.product sysctl and in dmesg.
Fuel and Origin 350 are no longer reported as being Origin 300 systems!
|
|
the *{X,}Bow names and because this is what IRIX calls it.
|
|
on PIC; no functional change.
|
|
instead of two 32 bit halves, as the supposedly `upper 32 bits' register
ignores writes; makes interrupt on PIC route correctly.
|
|
|
|
xbow''; while there report vendor and product id of unknow xbow chips.
|
|
foo bricks (they differ by having PCI-X bridges instead of PCI bridges
but are otherwise built the same)
|
|
but we only care about the first for matching, so don't bother listing the
second one in xbowdevs, and fix the description.
|
|
registers to be programmed correctly.
|
|
OK miod@
|
|
this is a console device.
|
|
|
|
Tested by myself, sthen, oga, kettenis, and jasper.
Input from sthen and jasper.
ok kettenis
(Manpage follows shortly.)
|
|
systems. PIC was supposed to be mostly XBridge compatible, but a silicon
bug prevents it from working correctly if 32 bit register writes are used,
so the xbridge(4) code now needs to issue 64 bit writes.
In order to make this a bit more transparent, rebase all widget registers to
a 8 byte boundary, and provide a few inline accessors which will do the right
thing if you want 32 bit writes.
Tested to not cause regressions on Octane, Origin 200 and Fuel; covering
Bridge < 4, Bridge >= 4 and XBridge flavours.
|
