requires us to configure the IOPLUS to use the appropriate DMA channel,
depending on what other expansion cards may be installed. Further, we need
to do a bit more configuration of the sq(4) DMA engine, which apparently
was formerly being configured properly by the PROM. Use the same values,
which appear to work fine.
Also, extend the gio_arb_config interface as needed.
NB: We're currently setting the IOPLUS board to long burst, but it may be
better to use realtime. This will require some experimentation.
reliably supporting badaddr(). False negatives appear to occur
approximately 1.8 percent of the time, although neither false positives
nor consecutive false negatives occur. We take advantage of the latter
property and always use a wrapper that makes multiple checks.
My IP12 no longer sees occasional ghost devices and related panics during
boot.
Devices present on the GIO bus needn't always provide a Product
Indentification Word, even if their address space is the same as the
address space of a slot. Separate the handling of probing for slot-based
devices and graphics devices, matching the latter first, and precluding
addresses probed for the former when a graphics device is known to exist
in a slot's space.
GIO slots. This differs from Indy, which has an interrupt per slot, neither
of which is the same as on the other two machines.
This lets my Phobos G160 run in both slots in my Indigo2 and my E++ adapter
works in both slots in my Indigo.
behind custom PCI<->GIO bridges:
- Set Engineering GIO Fast Ethernet (TI ThunderLAN)
- Phobos G100 (DEC 21140?)
- Phobos G130 (DEC 21143)
- Phobos G160 (DEC 21143)
All boards present the chipsets' pci configuration registers at some
defined offset in their slots' address space as well as device registers.
We simply allow the MI pci subsystem to attach the devices.
This has been tested with a G130 board (DEC 21143) and works well on IP20
and IP24. The Set Engineering board attaches, works fine when receiving and
lightly transmitting, but chokes for unknown reasons on heavy transmits.
The tl(4) driver may need some fixing.
gio bus arbiter parameters via imc(4) or pic(4).
Slots are identified by name: GIO_SLOT_GFX, GIO_SLOT_EXP1, GIO_SLOT_EXP2.
Provide some helper functions for establishing interrupts associated with
each slot and obtaining product descriptions.
to the screen on which they are being called. The driver cannot guess
this by itself but it is needed to implement, at least, the getwschar and
putwschar functions in the correct place. There are no functional changes
yet.
Tested on i386 (vga, vga_raster, machfb, vesafb), macppc and sparc64.
Suggested and reviewed by macallan@.
* fills seem to be broken. Avoid filling large vertical regions; instead,
attempt to break it up into managable chunks. This doesn't work perfectly
either, so clear the screen row-by-row (which does work).
* Characters are now right-side-up
* the driver now uses screen coordinates properly.
With the exception of column erases (which fall prey to the fill issue), the
driver is now usable.
driver. Still some issues:
* framebuffer setup seems incomplete. Some drawing primitives work 100%
of the time, while others fail one in ten tries. Perhaps my board is
slightly broken, as the exact model as probed by ARCS seems to shift
between Elan and XS24 from time to time.
* characters are drawn bottom-up rather than top-down (as the wsfont
definitions expect).
* detect and store vc2 revision. This is (likely) the important factor in
determining the proper cursor offset, so add a bit of logic that does the
right thing on my revision 0 vc2. This will have to be determined
empirically, revision by revision.
* take a stab at detecting framebuffer depth. SGI does it quite differently,
but their algorithm doesn't work, so we'll do it along the same lines as
linux.
* implement newport_mmap() for use by X. The necessary xsrc commits have been
made (with the notable exception of the config/cf changes, which probably
shouldn't go in until 4.4.0 has been imported).
* Add resolution and depth variables to softc (for use in X driver, although
depth detection is currently problematic),
* Store more information about various chip revisions,
* Implement ioctls to help the X driver detect device presence and geometry.
christos