arguments, so that a device can tell if its memory and I/O spaces are
enabled. The flags are cleared, depending on the contents of devices CSR
registers, in the machine-independent PCI bus code.
This can be disabled (to save a bit of space) with the NO_KERNEL_RCSIDS
options, which is present but commented out in the ALPHA config file.
In ELF-format kernels, these strings are present in the kernel binary but
are not loaded into memory. (In ECOFF-format kernels, there's no easy way
to keep them from being loaded, so they _are_ loaded into memory.)
extent storage per interface unit (e.g. dwlpx, where there can be multiple
units per machine) to do so. Inspired by discussion with and changes from
Matt Jacob.
the chipset space init functions multiple times, since that would clobber
extent allocations made between the two calls. Also, deal with the
fact that the APECS and LCA no longer shared common chipset functions.
the same things, but the extent maps have to be managed differently,
since the two chipsets provide different memory and I/O region mapping
possibilities.
don't machine check when a PCI Master Abort is signalled. This can
happen, for instance, when configuration space for a device that isn't
present is examined. When this is detected, act like we normally would
when machine checks are posted while examining nonexistant devices.
even if PCI and the IDs are right), just for sanity, before declaring
success. Split the single 0x3b0 -> 0x3df allocation into three seperate
ones: 0x3b0 -> 0x3bc (leaving the 4 ports available for lpt),
0x3c0 -> 0x3cf, and 0x3d0 -> 0x3df. The former chunk has to be split
off if the lpt can exist there, and it's sort-of pretty to have each
group (based on second hex digit) have its own handle.
front-ends. Unfortunately, because of the way ISA and PCI are currently
probed, if you have a PCI VGA board in your machine and both drivers
in your kernel, the ISA VGA driver may accidentally match the PCI board.
For now, the only solution to this is to not put both drivers in
the GENERIC kernels.
the Digital Semiconductor AlphaPC 164 Motherboard Technical Reference
Manual. This may not work, but it's the best i can do with the
documentation I have.
21164 + 21172 box, with Yet Another Way of doing interrupts. The
interrupt mapping and handling code hasn't been written yet, and none
of this code has been tested. (Checkpoint of work in progress.)
a char *, because that's what was really intended, and because
if the print function modifies the string, various things could become
unhappy (so the string should _not_ be modified).
figure out the correct IRQ for the ethernet on the AlphaStation 500.
That code is enabled via KN20AA_BOGUS_IRQ_FROB (but hopefully won't be
needed any time soon, and won't link w/o slight changes to other code).
Basically, when establishing an interrupt that we don't know what to
do with, prompt the user for what interrupt line to enable. If you
get stray interrupts when you try to use the device (but not before),
then you've got the right line.
found on the AlphaStation 600), and interrupts on interrupt line 13.
Thanks to Andrew Gallatin for booting a test kernel 32 times (trying
each interrupt line, looking for the right one) to find this.
mapping code. (instead of using a "slot" and multiplying by 4 and adding the
pin number later to get the IRQ, just use base IRQ value and add the pin
number.)
>Update for present reality (function names), clean up a bit (printfs,
>"panic: foo XXX"), and fix a couple of printf format specified bugs
>(which were normally #if 0'd out). Inspired by Multia/UDB support
>changes sent by Matt Thomas.
and:
>changes from Matt Thomas so that the Multia/UDB can attach its
>'com' interrupts, cleaned up some. Basically: if sharing type of
>new interrupt is different than what the hardware is currently set up
>for (e.g. requesting edge-triggered and the hardware is set up by
>the PROM for level triggered) and there are no interrupt handlers on
>that line already, warn about it and use the hardware type that the
>line was already set for (to avoid making the console blow up on
>reboot). If same circumstances but there is already a handler, panic
>as before.
common back-ends that live on multiple very-different busses (e.g. PCI and
TC), which need bus-specific DMA mapping support. As a nice side effect,
this will allow the especially nasty (vtophys(va) | 0x40000000) expressions
to go away in favor of less nasty bus-specific function calls.
from the current apecs_pci.c. This new version hopefully works for
the same sets of devices that that previous one did, and hopefully
will work for multi-function devices and for secondary PCI busses as
well. (looking at the code, there was no way the old one could have!)
cgd