#
e223e8e9 |
|
29-May-2023 |
Augustin Cavalier <waddlesplash@gmail.com> |
kernel/x86: Initialize IO-APIC only after PCI enumeration is complete. Before the PCI refactor, PCI initialization/enumeration occurred immediately after the PCI module was loaded, and so by the time we got to IOAPIC initialization, it was already complete. After the refactor, PCI enumeration is deferred until slightly later, and so we would try to initialize IO-APICs without knowing PCI information. This would fail, as read_irq_routing_table needs to have that available. Hopefully fixes #18425, #18393, #18398. Change-Id: I1e4b06367da26eeb10085a1c6322ed39885b632b Reviewed-on: https://review.haiku-os.org/c/haiku/+/6476 Reviewed-by: X512 <danger_mail@list.ru> Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
8908aef9 |
|
13-May-2011 |
Michael Lotz <mmlr@mlotz.ch> |
* Don't map the IO-APIC within the bootloader. We don't need it to set up SMP at all and, since there can be multiple IO-APICs, we need to do the enumeration again in the kernel anyway. Also only set ioapic_phys the first time we encounter an IO-APIC object as it looks cleaner when we arrive at the first IO-APIC default address. * Therefore we don't have to worry about already mapped IO-APICs when enumerating them in the kernel. * Also remove the mapping function that is now not used anymore. * We still use the ioapic_phys field of the kernel args to determine whether there is an IO-APIC at all to avoid needlessly doing the enumeration again. This fixes multi IO-APIC configurations, because before we would indeed map the last IO-APIC listed in the MADT, but then in the kernel assumed we mapped the first one. We'd end up with mapping the last listed IO-APIC twice and the first IO-APIC never, always programming the last one when we actually targetted the first one. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41476 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a56cbb2a |
|
11-May-2011 |
Michael Lotz <mmlr@mlotz.ch> |
* When initializing MSI support, don't assume a single 24 entry IO-APIC. Instead mark the ISA interrupts as unusable and then use ioapic_is_interrupt_available to determine if that vector is possibly taken by an IO-APIC. If IO-APICs are not used, this will simply always return false, leaving all vectors free for MSI use. * The msi_init() now has to be done after a potential IO-APIC init, so it is now done after ioapic_init() instead of inside apic_init(). * Add apic_disable_local_ints() to clear the local ints on the local APIC once we are in APIC mode (i.e. the IO-APIC is set up and we don't need the external routing anymore). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41445 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dc14d97b |
|
10-May-2011 |
Michael Lotz <mmlr@mlotz.ch> |
* Move the legacy PIC and the IO-APIC code into their own source file. No functional change intended. * Use an appropriately sized sLevelTriggeredInterrupts for each controller type. This also fixes an out of bound access for IO-APICs with more than 32 entries and also returns the right mode in such cases. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41426 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8908aef9c2c62225bce2d8216e81397c872316e8 |
|
13-May-2011 |
Michael Lotz <mmlr@mlotz.ch> |
* Don't map the IO-APIC within the bootloader. We don't need it to set up SMP at all and, since there can be multiple IO-APICs, we need to do the enumeration again in the kernel anyway. Also only set ioapic_phys the first time we encounter an IO-APIC object as it looks cleaner when we arrive at the first IO-APIC default address. * Therefore we don't have to worry about already mapped IO-APICs when enumerating them in the kernel. * Also remove the mapping function that is now not used anymore. * We still use the ioapic_phys field of the kernel args to determine whether there is an IO-APIC at all to avoid needlessly doing the enumeration again. This fixes multi IO-APIC configurations, because before we would indeed map the last IO-APIC listed in the MADT, but then in the kernel assumed we mapped the first one. We'd end up with mapping the last listed IO-APIC twice and the first IO-APIC never, always programming the last one when we actually targetted the first one. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41476 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a56cbb2afbf4dbfb4a07dfdd95f10637a195a053 |
|
11-May-2011 |
Michael Lotz <mmlr@mlotz.ch> |
* When initializing MSI support, don't assume a single 24 entry IO-APIC. Instead mark the ISA interrupts as unusable and then use ioapic_is_interrupt_available to determine if that vector is possibly taken by an IO-APIC. If IO-APICs are not used, this will simply always return false, leaving all vectors free for MSI use. * The msi_init() now has to be done after a potential IO-APIC init, so it is now done after ioapic_init() instead of inside apic_init(). * Add apic_disable_local_ints() to clear the local ints on the local APIC once we are in APIC mode (i.e. the IO-APIC is set up and we don't need the external routing anymore). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41445 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dc14d97b7f70aa318483d53e007913b26a12f5d0 |
|
10-May-2011 |
Michael Lotz <mmlr@mlotz.ch> |
* Move the legacy PIC and the IO-APIC code into their own source file. No functional change intended. * Use an appropriately sized sLevelTriggeredInterrupts for each controller type. This also fixes an out of bound access for IO-APICs with more than 32 entries and also returns the right mode in such cases. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41426 a95241bf-73f2-0310-859d-f6bbb57e9c96
|