| Age | Commit message (Collapse) | Author |
|---|
|
|
|
subdevices; use this on iockbc to only perform the fuel workaround on the
onboard ioc.
|
|
do this for us; PS/2 ports on CADduo boards attach keyboard and mouse now.
ok jsing@
|
|
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.
|
|
ioc(4) devices. Joint work with miod@.
Committed from the glass console on an SGI 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.
|
|
attach, print it, and decide how many RX descriptors to use accordingly.
|
|
lack of such hardware.
|
|
as the onboard ioc device, if one has already been found on this node.
Also, on Origin 300, do not attempt to attach the PS/2 controller on the
onboard ioc(4) since PS/2 ports are not wired.
|
|
system type list (which really is the system family) and a subsystem type.
No functional change yet.
|
|
|
|
00:00:00:00:00:00, in order to trigger the code which will assign a `feel bad'
random address.
|
|
far, and needs help to figure out its Ethernet address on IP35 systems.
Heavily derived from mec(4) written by Izumi Tsutsui and Christopher Sekiya,
although it required many changes to fit the IOC3 chip.
|
|
figure out how the interrupt was routed from xbridge to xheart... (it bypasses
the regular `have xbridge send a xio interrupt packet' mechanism)
|
|
specified in the kernel configuration file, but is provided by macebus(4)
as part of the child device attachment args, and provide both crime and
mace interrupt bitmasks; this allows us to only really enable interrupt
sources we care about, and to avoid invoking interrupt handler we don't need
to for the few mace interrupts multiplexed at the crime level.
|
|
|
|
Still unimplemented for now.
|
|
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!
|
|
pick the right clock if the PCI bus the I/O board is on degrades to 33MHz.
|
|
|
|
|
|
Tested by myself, sthen, oga, kettenis, and jasper.
Input from sthen and jasper.
ok kettenis
(Manpage follows shortly.)
|
|
Origin 350 and Tezro systems. While this chip provides serial ports, an ATAPI
interface and a PS/2 keyboard and mouse interface, this code currently only
attempts to support the serial ports.
|
|
commented symbolic constants.
|
|
ethernet driver attaches; prevents interrupt storms on Octane caused by
the way ARCS initializes the chip, when not booting from the network.
|
|
|
|
otherwise. Found the hard way by jasper@, playing with a bge card.
|
|
bus_space_handle_t, pass them ioc's own bus_space_handle and bus_space_tag,
and have the children use bus_space_subregion() on it.
|
|
|
|
PCI ROM into account, if any.
|
|
|
|
|
|
- do not use a stinking extent to track bus_space_map allocations, but
directly map in XKPHYS instead. What are 64 bit address spaces good for
if we still need to use TLB for that?
- provide proper resource management extents to the MI pci code, so that,
in turn, the cardbus code can reuse them instead of providing their own.
- use the whole 4GB address space window for PCI I/O resources, just
because we can.
- make sure no device can get assigned address zero in I/O space, because
this address triggers a PCI error.
|
|
class systems. Tested on O2 and Origin 200 with wi@pcmcia and xl@cardbus,
using a Ricoh 5C475-based cbb(4) board.
acx@cardbus doesn't work reliably yet, so your mileage may vary until more
bugs are fixed.
Thanks to matthieu@ for lending me some cardbus devices for testing.
|
|
The firmware messes up I/O BARs, so whack those back to 0, such that the MI
PCI code initializes on an as-needed basis.
ok miod@
|
|
where the common part to all bus_dmamap_load*() functions is implemented in
in an internal load_buffer routine.
This allows the xbridge-specific dma code to only provide this function,
instead of three; and this also brings us a working bus_dmamap_load_uio()
on all supported sgi machines, which in turns make crpyto(4) devices really
work. Tested with hifn(4).
|
|
|
|
per-pci_chipset_t function to perform actual resource allocation.
Add the necessary bits to macepcibr(4), and enable ppb(4) on O2 kernels now.
Joint effort with kettenis@
|
|
configuration register; this allows the driver to select ultra speed, which
this particular hardware supports.
From Linux, ok kettenis@
|
|
bridge initialization if necessary; enable ppb on IP27 and IP30 kernels.
With feedback from kettenis@; macepcibr to gain the same functionality soon.
|
|
Octane support. The Octane being a single-node system, address space is
ludicrous enough to allow the whole address space of every widget to be
directly accessible in whole, using the address bits reserved to nasid.
However, on IP27 and IP35, things do not work this way - while we still have
the low 16MB address space of each widget available (the so-called
``short window''), access to other parts of the wiget address space is done
through translation slots (IOTTE) at the Hub I/O space level, on a per-node
basis.
Given the imminent release lock, give up completely on ``large'' mappings
of widgets, and restrict ourselves to short window operation, all the time
(thus reinforcing the use of devio registers to map pci resources on xbridge).
A proper interface to request mappings of specific widget areas, either
directly on Octane, or through IOTTE if available on Origin, will appear
post-release.
No functional change (except from silently repairing Octane support which the
previous xbridge commit silently broke).
|
|
is still unhappy due to ``interferences'' between the L1 console and the
brick's serial ports, unfortunately.
|
|
used by onboard IOC chips, by forcing the IOC to trigger this interrupt,
and some help from the PCI bridge driver to report which interrupt has
fired through a fake PCI configuration register.
This works nicely on IP27 and IP35, but on IP30 the interrupt doesn't
happen, for some reason; so keep the existing heuristic in case the above
trick did not give us a valid interrupt number.
In case we got an interrupt, this will also detect IOC configurations where
there is actually one interrupt, should such configurations exist.
<rant style="beck">
I probably deserve to rot in hell for this abomination, but I won't mind
as long as the IOC designers who came with the bright ``let's use more than
one interrupt and defecate on the pci spec'' ideas are there, too.
</rant>
|
|
|
|
config_search(), so that disabled or unconfigured child device appear in
dmesg as ``not configured''.
|
|
|
|
information, instead of trying to attach whatever is defined in the
kernel configuration file.
|
|
have a shared ethernet/superio interrupt source, so deal with this.
|
|
adressing (no problem since we only support 64-bit mode).
ok miod@, jsing@
|
