Provide an interrupt availability check callback instead of a maximum IRQ
number. This accounts for possible gaps in the IO-APIC GSI mappings. Since most
of the time there will be only a single IO-APIC the extra overhead is relatively
small.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41431 a95241bf-73f2-0310-859d-f6bbb57e9c96

Use const references instead of pointers for the print functions.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41417 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Choose the desired configuration of the link devices at preparation time
already. This allows to detect invalid settings before starting to enable
IRQ routing and therefore allows to gracefully fall back to PIC mode on error.
* Actually read the number of IO-APIC entries before using that number in
routing preparation.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41416 a95241bf-73f2-0310-859d-f6bbb57e9c96

Check hardwired and chosen IRQs against the maximum we can address. Try to fail
gracefully in such cases (resulting in the IO-APIC not being used).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41415 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Balance the IRQs amongst the possible ones. A simple usage counter, filled by
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

* Seperated out reading and enabling IRQ routing. Reading will only read the
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

* Separate out matching PCI devices and updating their info. They will be called
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

Read and keep around the originally assigned interrupt_line of the PCI devices.
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

Actually use the ACPICA headers to get at the correct types instead of
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

Reimplement the IRQ setting function. Based on the template we get from current
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

* Implement the PCI address retrieval on the kernel side and remove the need
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

* Added functionality to resolve the addresses provided in the IRQ routing table
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

Remove wrong comment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41329 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Change some of the structure fields to more sensible types.
* The irq values we get from ACPICA are already converted, remove the wrong
extra conversion from bitfield to irq number.
* Add and handle extended irq structures.
* Disable the legacy PIC when done configuring the IOAPIC. Since during that
configuration the ACPI module is initialized, the ACPI SCI is still enabled
in the PIC instead of the IOAPIC. We'll have to delay that routing in the
ACPI module for it to work.
* Correctly handle the fixed IRQ case for the PCI interrupt routing (hopefully).
* Actually allow for enumeration of possible IRQ settings. Not yet used though.

All of this brings us a bit closer, though it still won't work for PCI
interrupts. ISA interrupts work fine through the IOAPIC as far as my hardware
goes, but PCI interrupts are connected to dedicated IOAPIC pins and I still
haven't figured out how to determine their exact routing.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41328 a95241bf-73f2-0310-859d-f6bbb57e9c96

Cleanup and a minor debug output change.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41313 a95241bf-73f2-0310-859d-f6bbb57e9c96

Just some cleanup. We won't need pci module for setup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41025 a95241bf-73f2-0310-859d-f6bbb57e9c96

First version of reading IRQ's that returns proper results.
There are TODO's in here, because the ACPI module needs restructuring and which I will take care of.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38289 a95241bf-73f2-0310-859d-f6bbb57e9c96

Mismatch with ACPI definition.
(Refactoring ACPI never looked so good...)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38283 a95241bf-73f2-0310-859d-f6bbb57e9c96

* embedded_controller_support() now actually checks all entries of the
supporting ID array (just that it only contains one entry).
* Fixed missing malloc() result check in embedded_controller_init_driver().
* Style fixes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36529 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moving ACPI Embedded Controller to ACPI bus manager.
* Removed irq_routing struct from ACPI.h to where it is used. Might be able to use acrestype.h instead of duplication.
* Disable old embedded controller and remove it from image.
* Move embedded controller code to busmanager module.
* Remove (some) code duplication

Should work as before, but is now initialized right after the bus manager. Can probably remove further code duplication.
I hope I've done it correctly, feedback is most welcome.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36420 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix spelling, pointed out by Stefano and Axel.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36139 a95241bf-73f2-0310-859d-f6bbb57e9c96

Rescue acpi irq stuff from my defect laptop. Code is disabled and should't to any harm.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36059 a95241bf-73f2-0310-859d-f6bbb57e9c96

Provide an interrupt availability check callback instead of a maximum IRQ
number. This accounts for possible gaps in the IO-APIC GSI mappings. Since most
of the time there will be only a single IO-APIC the extra overhead is relatively
small.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41431 a95241bf-73f2-0310-859d-f6bbb57e9c96

Use const references instead of pointers for the print functions.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41417 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Choose the desired configuration of the link devices at preparation time
already. This allows to detect invalid settings before starting to enable
IRQ routing and therefore allows to gracefully fall back to PIC mode on error.
* Actually read the number of IO-APIC entries before using that number in
routing preparation.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41416 a95241bf-73f2-0310-859d-f6bbb57e9c96

Check hardwired and chosen IRQs against the maximum we can address. Try to fail
gracefully in such cases (resulting in the IO-APIC not being used).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41415 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Balance the IRQs amongst the possible ones. A simple usage counter, filled by
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

* Seperated out reading and enabling IRQ routing. Reading will only read the
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

* Separate out matching PCI devices and updating their info. They will be called
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

Read and keep around the originally assigned interrupt_line of the PCI devices.
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

Actually use the ACPICA headers to get at the correct types instead of
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

Reimplement the IRQ setting function. Based on the template we get from current
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

* Implement the PCI address retrieval on the kernel side and remove the need
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

* Added functionality to resolve the addresses provided in the IRQ routing table
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

Remove wrong comment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41329 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Change some of the structure fields to more sensible types.
* The irq values we get from ACPICA are already converted, remove the wrong
extra conversion from bitfield to irq number.
* Add and handle extended irq structures.
* Disable the legacy PIC when done configuring the IOAPIC. Since during that
configuration the ACPI module is initialized, the ACPI SCI is still enabled
in the PIC instead of the IOAPIC. We'll have to delay that routing in the
ACPI module for it to work.
* Correctly handle the fixed IRQ case for the PCI interrupt routing (hopefully).
* Actually allow for enumeration of possible IRQ settings. Not yet used though.

All of this brings us a bit closer, though it still won't work for PCI
interrupts. ISA interrupts work fine through the IOAPIC as far as my hardware
goes, but PCI interrupts are connected to dedicated IOAPIC pins and I still
haven't figured out how to determine their exact routing.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41328 a95241bf-73f2-0310-859d-f6bbb57e9c96

Cleanup and a minor debug output change.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41313 a95241bf-73f2-0310-859d-f6bbb57e9c96

Just some cleanup. We won't need pci module for setup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41025 a95241bf-73f2-0310-859d-f6bbb57e9c96

First version of reading IRQ's that returns proper results.
There are TODO's in here, because the ACPI module needs restructuring and which I will take care of.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38289 a95241bf-73f2-0310-859d-f6bbb57e9c96

Mismatch with ACPI definition.
(Refactoring ACPI never looked so good...)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38283 a95241bf-73f2-0310-859d-f6bbb57e9c96

* embedded_controller_support() now actually checks all entries of the
supporting ID array (just that it only contains one entry).
* Fixed missing malloc() result check in embedded_controller_init_driver().
* Style fixes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36529 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moving ACPI Embedded Controller to ACPI bus manager.
* Removed irq_routing struct from ACPI.h to where it is used. Might be able to use acrestype.h instead of duplication.
* Disable old embedded controller and remove it from image.
* Move embedded controller code to busmanager module.
* Remove (some) code duplication

Should work as before, but is now initialized right after the bus manager. Can probably remove further code duplication.
I hope I've done it correctly, feedback is most welcome.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36420 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix spelling, pointed out by Stefano and Axel.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36139 a95241bf-73f2-0310-859d-f6bbb57e9c96

Rescue acpi irq stuff from my defect laptop. Code is disabled and should't to any harm.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36059 a95241bf-73f2-0310-859d-f6bbb57e9c96