- Use PCI_INTERRUPT_PIN_MAX and I386_PCI_INTERRUPT_LINE_NO_CONNECTION
instead of magic number.
the Following changes are
{Modified with,Approved by} UCHIYAMA Yasushi <uch@netbsd.org>:
- Do not touch a PIRQ router, if the PIRQ is already routed
by the BIOS, or no appropriate IRQ is found for the PIRQ.
The latter prevents a panic on the machine of Frank van der Linden.
- Do not modify a PCI Interrupt Configuration register,
if it is already set by the BIOS, even if it is inconsistent
with the PCI IRQ routing table provided by the BIOS.
(The PCI Interrupt Configuration register seems to be more reliable
than the PCI IRQ routing table.)
This is needed to prevent a incorrect header_fixup() caused
by the incorrect PIR table on a Panasonic Let's Note AL-N2T516J5.
Provide "options PCIBIOS_INTR_FIXUP_FORCE" to retain
previous behavior, i.e. believe the PCI IRQ routing table
and ignore the PCI Interrupt Configuration register.
Although I'm not sure this is really needed.
- Do not modify a PCI Interrupt Configuration register,
if appropriate IRQ is not found for the link.
- Move a pciintr_icu_getclink() call and a pciintr_icu_get_intr()
call from pciintr_link_fixup() to pciintr_link_alloc(),
and only allocate pciintr_link_map if those calls succeeded.
This reduces number of calls of pciintr_icu_getclink(),
and also avoid necessity to validate a clink value in
ICU's {get,set}_{intr,trigger}() functions.
The sanity checks are not removed yet, though.
- Fix uninitialized usage of variable `bitmap' on stage 3
of pciintr_link_fixup().
- Remove a member variable `old_irq' from struct pciintr_link_map.
- Always use 0x%02x for printf format of canonical link value.
- Use DIAGNOSTIC instead of PCIINTR_DEBUG for really weird situation.
to prevent a panic on a Panasonic Let's Note AL-N2T516J5.
- add several debug printf which can be enabled by FIRESTARDEBUG.
by UCHIYAMA Yasushi <uch@netbsd.org>
- use I386_PCI_INTERRUPT_LINE_NO_CONNECTION instead of magic number.
<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.
Some PCI soundcards don't seem to use the generic gameport function with
interface 0x10 used here, but have either an own BAR dedicated to this
(i.e. Sonic Vibes or ESS Solo-1) or specify their own device (see
PCI_PRODUCT_CREATIVELABS_SBJOY in sys/dev/pci/pcidevs.h).
Probably these use a similar simple sheme and adding a frontend for them would
be trivial, but I don't own any of these cards, so I didn't.
entries for the IRQs used by the IDE controller, which aren't really
PCI IRQs (they're ISA compat IRQs), and thus have link values that
don't make a lot of sense.
patches, cleaned up and heavily reworked by me. Basic algorithm is
the same, although the code structure is now quite different.
Main differences:
- Initialization path is totally different.
- We use the `compat router' information, if present, to determine which
PCI ICU driver we should use.
- Fixup configuration headers on devices not on bus 0.
out from UCHIYAMA Yasushi's PCI BIOS patches, and fairly heavily reworked
by me.
Main differences:
- Only use the PCI BIOS to get the config mechanism and interrupt routing
info for now. No need to use the BIOS for PCI config access right now,
since the old mechanism works fine, and this keeps the code smaller.
- PCI BIOS initialization code path is much different.
- Always use the $PIR table if it exists, and only fallback to the
PCI BIOS 2.1 GetInterruptRouting call if it's not there.
This module does not include any of the fixup code; that is coming
in separate commits.
2 reasons:
-no need to keep a list of all known parts
-there is at least 1 bridge (ACC micro 2051) which reports the same
device ID for its various subfunctions; this would require an additional
check in the match function
(keep the old list inside #if 0 in case one of the historical bridges
doesn't report the right class/subclass - I can't check them all)
and i/o enabled) should be passed to the primary PCI bus's autconfiguration
node. Use this function to detect broken PCI-Host bridges, which have
problems with memory-mapped access. Add the SIS 85C496 to this list.
primarily to nicely print version information about your PCI chipset
(try with "options PCIVERBOSE"). Eventually, it may be used to
enable/disable features/bugs of a given PCI chipset. In addition, this
driver uses the PCI-ISA bridge callback mechanism to logically attach the
ISA bus to the PCI-ISA bridge.
driver is a place-holder, which will nicely print version information
about your PCI chipset (try with "options PCIVERBOSE"). Eventually,
this can be used to enable/disable features/bugs of individual PCI
chipsets.
- No more distinction between i/o-mapped and memory-mapped
devices. It's all "bus space" now, and space tags
differentiate the space with finer grain than the
bus chipset tag.
- Add memory barrier methods.
- Implement space alloc/free methods.
- Implement region read/write methods (like memcpy to/from
bus space).
This interface provides a better abstraction for dealing with
machine-independent chipset drivers.
(soon to be documented on mailing lists; eventually in section 9 manual
pages), most importantly:
(1) support interrupt pin swizzling on non-i386 systems with
PCI-PCI bridges (per PPB spec; done, but meaningless, on i386).
(2) provide pci_{io,mem}_find(), to determine what I/O or memory
space is described by a given PCI configuration space
mapping register.
(3) provide pci_intr_map(), pci_intr_string(), and
pci_intr_{,dis}establish() to manipulate and print info about
PCI interrupts.
(4) deprecate the pci_map_* functions, and provide them only
as compatibility interfaces (in pci_compat.c) which will
eventually go away, implemented as wrappers around
the functions described above.
(5) make pci functions take as an argument a machine-dependent
cookie, to allow more flexibility in implementation.
hook (pci_md_attach_hook()) to do any machine-dependent attachment
gunk, e.g. on the i386 printing out the configuration mode (if bus 0)
(2) don't pass max device number for a given bus in, use
PCI_MAX_DEVICE_NUMBER, which can be defined on a per-machine basis.
(defaults to 32. on i386, it's 32 if pci conf mode == 1, 16 if 2.)
