by the initial PCI_NETBSD_CONFIGURE, nor should it be manually wired by
the indirect stuff. This is all taken care of by the prep_init() function.
7025-F40 support supports the primary pci bus only. The second PCI bus
on the machine is still unsupported, but the machine runs and can access
everything except for the two slots the other bus covers.
The bug displayed itself by locking up console output on a 7043-140
following a powercycle. This may also have been the cause of bogus
interrupts on motorola class machines.
1) Rather than build an array of the pci->intr mappings, build a proplib
tree.
2) add a SIMPLEQ of device properties to the pci_chipset_tag to hold the
proplib trees of each bus.
3) Move the interrupt routing code from pci_conf_interrupt to pci_map_intr()
4) Deal properly with non-native PCI bridge chips that are not recognized
by the prep firmware, and therefore are not noted in the residual data.
The major win of this restructure is #4. Hopefully I haven't broken
anything. Tested on a 7248-100, 7043-140 and 7024-E20.
models. This code was made possible by assistance from Cory Bajus.
Add code that asks the PCI bridge what it's config base address is, and
use that when wiring up an indirect bridge type.
Move prep's user segment register to 10, because the 7025's PCI config
address is at 11, where the user segment used to be.
Add a battable entry for 0xbf800000 for machines with RS6K bridges.
There is still probably work left to be done before a 7025-F40 is fully
supported.
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@.
1) create new pnpbus psuedo bus. This is a bus layer that reads the PNP
tree from the residual data and allows attachment of devices with the
information given therein. Based loosely on i386/pnpbios.
2) Delete obio bus, as with the pnp bus we no longer need it.
3) Create a number of functions that gather the information needed to set
up the machine from the residual data, rather than hardcoding it in.
4) Create a quirk table for machines that are bizzare enough that the
residual information is not sufficient. (such as the 6015)
5) Using the data gathering routines and the quirk table, delete struct
platform completely from the architecture. Prep is now almost completely
dynamic in figuring out the machine it is running on and setting things
up properly.
6) Add a wdc_pnpbus driver which attaches the wdc controller found on
some 7248's and the 6015. This replaces the now-defunct wdc_obio.
7) delete all the mot_* and ibm_* files, and replace them with a single
ibm_machdep.c which only contains the quirk functions for the 6015 and
the 6050.
8) Modify GENERIC to work with all this stuff.
Changes:
Added a pci-EISA bridge device and associated glue to the prep port.
Adapted from i386.
Change pci_intr_fixup_*() to pass the pin argument on all platforms.
Make PCI_NETBSD_CONFIGURE leave the MPIC alone. We map it separately.
7024 kernel was also succ. tested on an IBM 7043, so no regression there.
which bustype should be attached with a specific call to config_found()
(from a "mainbus" or a bus bridge).
Do it for isa/eisa/mca and pci/agp for now. These buses all attach to
an mi interface attribute "isabus", "eisabus" etc., and the autoconf
framework now allows to specify an interface attribute on config_found()
and config_search(), which limits the search of matching config data
to these which attach to that specific attribute.
So we basically have to call config_found_ia(..., "foobus", ...) where
such a bus is attached.
As a consequence, where a "mainbus" or alike also attaches other
devices (eg CPUs) which do not attach to a specific attribute yet,
we need at least pass an attribute name (different from "foobus") so
that the foo bus is not found at these places. This made some minor
changes necessary which are not obviously related to the mentioned buses.
copyin() or copyout().
uvm_useracc() tells us whether the mapping permissions allow access to
the desired part of an address space, and many callers assume that
this is the same as knowing whether an attempt to access that part of
the address space will succeed. however, access to user space can
fail for reasons other than insufficient permission, most notably that
paging in any non-resident data can fail due to i/o errors. most of
the callers of uvm_useracc() make the above incorrect assumption. the
rest are all misguided optimizations, which optimize for the case
where an operation will fail. we'd rather optimize for operations
succeeding, in which case we should just attempt the access and handle
failures due to insufficient permissions the same way we handle i/o
errors. since there appear to be no good uses of uvm_useracc(), we'll
just remove it.
indicating an unhandled "command". ERESTART is -1, which can lead to
confusion. ERESTART has been moved to -3 and EPASSTHROUGH has been
placed at -4. No ioctl code should now return -1 anywhere. The
ioctl() system call is now properly restartable.
as direct-mapped PCI configuration space access (such as implemented on
the IBM 27-82650 PCI Host Bridge), switch to a function vector based
PCI configuration space access implementation. The appropriate PCI
chipset tag is provided by platform-specific code.
files.prep:
- add new files entry.
pci_machdep.c:
- use dev/pci/pciconf.c instead of mine for pci io/mem addr/intr fixup.
cpu.c:
- separate code
machdep.c:
- call ident_platform()
mainbus.c:
- call pci_configure_bus(), if defined PCI_NETBSD_CONFIGURE
ibm_machdep.c:
- for IBM PReP generic
ibm_6050.c:
- for IBM Personal Power Series 830/850
ibm_7248.c:
- for IBM RS6000/43P deppendency
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
<vm/pglist.h> -> <uvm/uvm_pglist.h>
<vm/vm_inherit.h> -> <uvm/uvm_inherit.h>
<vm/vm_kern.h> -> into <uvm/uvm_extern.h>
<vm/vm_object.h> -> nothing
<vm/vm_pager.h> -> into <uvm/uvm_pager.h>
also includes a bunch of <vm/vm_page.h> include removals (due to redudancy
with <vm/vm.h>), and a scattering of other similar headers.
