hardwired GSIs and updated on configuring the link devices, is used for that.
This doesn't guarantee optimal results as some link devices may not be
configurable to some IRQs and we might fill up their slots this way. Most of
the time this should be good enough though.
* Take the BIOS assigned IRQ white list into account when assigning IRQs in the
ISA range and avoid assigning to non white listed IRQs. Quite probably it'd be
ok to use all of the IRQs present in the possible IRQ list, but let's play it
safe...
* Also white listed are the IRQs that were set on the link device before
reconfiguration.
* Some cleanup, use references instead of pointers where applicable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41401 a95241bf-73f2-0310-859d-f6bbb57e9c96
configuration that doesn't require any link device changes and will only
prepare for updating the pci_info. Enabling then does the link device setup
and updates the pci_info with the new IRQ values.
* Configuring link devices now takes into account that multiple devices may
share a single link device, meaning that the sharing PCI devices can't be
configured independently.
We still only blindly configure the first possible IRQ on the link devices, but
now we actually have all the information to change that. Working on that next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41400 a95241bf-73f2-0310-859d-f6bbb57e9c96
independently. Matching will happen first to enumerate and match all devices.
Updating will happen after configuring all link devices, so once we know the
final GSI of all entries. The info about matching functions is kept in a
bitmask in the table entry.
* Move routing table entry handling out of the loop into it's own function to
faciliate early returns.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41399 a95241bf-73f2-0310-859d-f6bbb57e9c96
Those can be used to white list PCI IRQs in ISA space (<= 15) as those are
basically guaranteed not to overlap with ISA devices. Those white listed entries
can then be used if we only have a 16 pin IO-APIC or if there are only legacy
IRQ resources available for configuration (i.e. ones with bitmasks of 16 bits,
limiting their range to IRQs 0-15).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41397 a95241bf-73f2-0310-859d-f6bbb57e9c96
using the already parsed pci_info data from the PCI module. This removes the
need to iterate over all of the pci_infos for each routing table entries which
makes this an order of magnitude less expensive. Heavily inspired by the
corresponding FreeBSD code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41395 a95241bf-73f2-0310-859d-f6bbb57e9c96
duplicating the structs on our side. IRQ assignment didn't work with extended
IRQ resources because the alignment of the structs were different in our local
duplicates...
Brings in the ACPICA naming sheme and isn't really clean either. So all of the
reconfiguration should probably just be moved into the ACPI bus_manager.
On the plus side we can now use the proper descriptive macros instead of the
hardcoded numbers which fixes a few of the TODOs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41393 a95241bf-73f2-0310-859d-f6bbb57e9c96
* length of utsname members must stay at length of 32
This will work just the same for now. When using a DVCS yields longer revisions, we need to adjust AboutSystem to fetch the full revision directly from the ELF section '_haiku_revision' (as found in libroot.so or libbe.so).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41392 a95241bf-73f2-0310-859d-f6bbb57e9c96
* increase _SYS_NAMELEN defined in sys/utsname.h to 128 to allow long(ish) revisions
* sHaikuRevision is now a static character array (in both libroot and kernel)
* adjust build tool set_haiku_revision to write the revision as string
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41389 a95241bf-73f2-0310-859d-f6bbb57e9c96
the first possible configuration. This will probably result in a "everything
mapped to a single IRQ" situation, but should get systems that make use of link
devices in APIC mode at least running.
To make more sensible decisions the interface has to be changed next as it
currently doesn't allow to get anything but the very first possible config.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41384 a95241bf-73f2-0310-859d-f6bbb57e9c96
resources we input the desired configuration and then set them. Note that the
set_current_resources() ("_SRS") method is pretty picky (on the low-level ACPI
side) and needs the configuration in exactly the form get_current_resources()
("_CRS") returns, so that's why we need to utilize that buffer as a template.
Looking at FreeBSD there seem to be systems that don't actually provide a
"_CRS", where we will need to fall back to using the get_possible_resources()
("_PRS") data to construct a valid template...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41383 a95241bf-73f2-0310-859d-f6bbb57e9c96
from settings retrieved through get_{current|possible}_resources().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41382 a95241bf-73f2-0310-859d-f6bbb57e9c96
* remove manual sDisplayMode and make use of mode_list_area via Axel's common accelerant code using vesa as example
* move mask enabled write32 function to accelerant with write32 calls
* move register offsets into mode.h headers
* rename DxMode* to CardMode*
* make adjustments and implement radeon hd mode setting further
* remove previously defined kStdModeTimings
* hardware mode setting still needs work
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41374 a95241bf-73f2-0310-859d-f6bbb57e9c96
turns out to be flaky, is a little bit of a hack anyway and performs unnecessary
operations. The functionality is now handled kernel side which optimizes those
problems away.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41372 a95241bf-73f2-0310-859d-f6bbb57e9c96
for the introduced get_pci_info() method in ACPI as it doesn't work reliably.
The new version should be more robust and efficient as it only resolves the
root bridge values once.
* Don't try to read and use the secondary bus register for the root bridge as
it isn't actually a normal bridge. We get the root bridge bus by using the
Base Bus Number (_BBN) method.
* Rewrite the logic to recurse down to all busses.
* Minor debug output changes to make the info more readable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41371 a95241bf-73f2-0310-859d-f6bbb57e9c96
IO-APIC can be easily enabled to test it on various configurations. Note that
the previous default opt-out didn't work because the safemode options would not
be touched at all when not actually entering the boot menu.
Once IO-APIC is more broadly tested this can be removed again and the opt-out
option reenabled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41370 a95241bf-73f2-0310-859d-f6bbb57e9c96
to PCI devices partly using the new ACPI interface and by using bridge config
information from PCI.
* Added lookup of matching device/pin combinations and update of the relevant
interrupt line variable via the new PCI module function. This means that the
Global System Interrupt (GSI) that is used after switching to the IO-APIC is
now stored in the PCI config space and drivers enumerating these devices will
now attach their interrupt handlers to the right IRQs.
* Resolve all relevant interrupt information directly into the irq_routing_entry
so that can be used as the single source for config information. This includes
resolving the current setting of any PCI link devices into the irq field that
represents a GSI now.
* Use that info to configure interrupts in arch_int.cpp and remove the logic
there.
* Some cleanup and added debug output.
This implements the final missing part for using IO-APICs and full APIC mode for
interrupt routing. Note that there is no quirk handling of any form, so this
may very well not work on some configurations. Note also that I have tested this
only on one machine so far. Once proper testing is done the default of disabling
the IO-APIC can be removed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41367 a95241bf-73f2-0310-859d-f6bbb57e9c96
the base bus number and segment which is what we're using them for. It should
work generically, however I only tested it to look up PCI bridge devices.
The logic is a subset of what is done in AcpiEvPciConfigRegionSetup when setting
up the operation region for a PCI device.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41365 a95241bf-73f2-0310-859d-f6bbb57e9c96
the cached pci_info and writes the new value into PCI config space. Drivers
using either mechanism to enumerate devices will therefore get the updated
value.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41364 a95241bf-73f2-0310-859d-f6bbb57e9c96
layout API, we probably can just phase it out after a while.
* Introduced new constructors, and added missing flags to one of them to make
it more convenient to use.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41350 a95241bf-73f2-0310-859d-f6bbb57e9c96
