| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
ARCS, except for IOC3 devices (which might be our console). This allows
us to build resource accounting extents to pass the MI code (for more magic).
|
|
work on systems with xbridge.
|
|
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).
|
|
which crept in the previous commit.
|
|
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@
|
|
bridge initialization if necessary; enable ppb on IP27 and IP30 kernels.
With feedback from kettenis@; macepcibr to gain the same functionality soon.
|
|
- introduce an interface for widget drivers to ask the xbow to map arbitrary
views of their address space, in addition to the low 16MB. This operation
may fail or map a subset range of what the caller asked for, depending on
the platform we're running on.
- use this in xbridge to set up views on the direct memory and i/o spaces,
to map devices resources when they don't fit in one of the devio small
ranges (limited to 2MB anyway). These views are only allocated when
devio can't do the job, so as not to consume too many resources on
Origin family systems where such views are scarce resources (and
shared accross the whole crossbow).
This makes pci devices with large resource needs configure correctly.
While there, fix programming of 64 bit memory BAR; this makes bge(4)
work.
Tested on Octane (with Bridge revision < 4 and >= 4), Origin 200 (Bridge >= 4)
and Fuel (XBridge).
ok deraadt@
|
|
whenever possible for devices with both i/o and memory resources; still
doesn't allow more than 2MB of mappings per device in each space, though.
|
|
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).
|
|
I/O resources, via devio.
Unfortunately it works as badly as when using the large window, so the bugs
I am hunting must come from elsewhere.
|
|
As long as I can't figure out what endianness knobs I need to frob to make
I/O and memory accesses through the large window work as intended, we are
stuck to devio I/O mappings only...
|
|
the loop. No functional change.
|
|
it if it does not fit in our extent, and force a suitable address. Prevents
extent sanity check panics with some cards.
|
|
be disabled with some UKC tinkering.
|
|
is still unhappy due to ``interferences'' between the L1 console and the
brick's serial ports, unfortunately.
|
|
|
|
extent, but isp(4) on other nodes do not work correctly yet.
|
|
|
|
|
|
and then restart system (NMI on these systems aren't intended to be
recoverable).
|
|
we have, in order to pick a widget enumeration order matching the PROM.
This is especially important when the boot path is in dksc() syntax.
|
|
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>
|
|
|
|
PCI buses on xbridge.
In addition to this, we now support the limited IOMMU, allowing memory
outside of the 2GB direct window to be used for DMA.
Only tested on XBridge chip so far; this lets an IP35 machine with
physical memory after the 2GB boundary run stable again.
|
|
IP27 logic will obviously not work there.
|
|
|
|
ask the Bridge to do this for us; this makes the initial interrupt deadlock
workaround functional again.
|
|
doesn't appear to trigger the expected interrupt, so use a fugly nanotimeout
instead.
This makes Origin 200 disks not stall as soon as some serious I/O is intended.
They now run multiuser.
|
|
connecting part of the XBow, as advertized by the KL graph. Hub specific
code already exists in xbow.c and will remain there.
|
|
xbridge(4) is assigned. Then, make bus_dmamem_alloc() allocate from this
range only.
This is transparent on O2, and makes sure the bus_dma memory address
will fit in the 2GB direct map of xbridge(4) chips - this is necessary for
PCI devices which do not handle 64 bit dma addresses.
|
|
|
|
code.
|
|
resources to cards not configured by the PROM. There are still some
shortcomings, but this is a good start.
Tested on IP35 with an fxp(4).
|
|
but (currently commented out) code makes isp happier on IP27 and IP35, to the
point of seeing disks (but considering them offline so far).
|
|
|
|
|
|
handle a mapping partly in, and partly out the direct DMA window, on
systems with > 2GB physical memory.
|
|
differently at times.
|
|
|
|
these are completely unrelated as long as there is only one pci bus per
bridge.
|
|
|
|
a complete physical address. Also add proper cpu pa<->device pa for dma
on Origin 200.
This lets xbridge work and route interrupts correctly on Origin 200.
|
|
some years ago for KL enumeration, building on the existing XBow support
to limit ourselves to a single node for now.
This is a work-in-progress; it currently lacks complete interrupt code,
as well as PCI resource management. And there are likely bugs creeping
inside.
|
|
hog the bus, and also to fake a valid interrupt register. The IOC3 device
is not a PCI device at all, but pretends to be one. Except its own
registers overlap the PCI configuration space, and some flavours do not
support disabling memory space in the control register, violating the PCI
specs. Fun.
|
|
|
|
|
|
|
|
ok miod@
|
|
endianness conversion on pci bridges.
ok deraadt@ jsing@
|
