dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Kernel/Bus/PCI/Device.cpp

205 lines
7.9 KiB
C++
Raw Normal View History

Kernel: Add the DeviceController class in the PCI subsystem Such device is not an IRQHandler by itself, but actually a controller of many IRQ or MSI devices. The purpose of this class is to manage multiple sources of interrupts. For example, a generic ISA IDE controller controls 2 IRQ sources - 14 and 15. So, when we initialize the IDE controller, it will initialize two IDE channels (also known as PATAChannels) to utilize IRQ 14 and 15, respectively. NVMe with MSI-X support can theoretically handle up to 2048 interrupts.
2020-12-18 05:52:52 -03:00
/*
* Copyright (c) 2020, Liav A. <liavalb@hotmail.co.il>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
Kernel: Add the DeviceController class in the PCI subsystem Such device is not an IRQHandler by itself, but actually a controller of many IRQ or MSI devices. The purpose of this class is to manage multiple sources of interrupts. For example, a generic ISA IDE controller controls 2 IRQ sources - 14 and 15. So, when we initialize the IDE controller, it will initialize two IDE channels (also known as PATAChannels) to utilize IRQ 14 and 15, respectively. NVMe with MSI-X support can theoretically handle up to 2048 interrupts.
2020-12-18 05:52:52 -03:00
*/
Kernel: Use AK:any_of in PCI::Device capability checks This is equivalent to std::any_of as clang-tidy suggests.
2021-12-08 09:42:21 -03:00
#include <AK/AnyOf.h>
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
#include <Kernel/Arch/Interrupts.h>
#include <Kernel/Arch/PCIMSI.h>
Kernel/PCI: Simplify the entire subsystem A couple of things were changed: 1. Semantic changes - PCI segments are now called PCI domains, to better match what they are really. It's also the name that Linux gave, and it seems that Wikipedia also uses this name. We also remove PCI::ChangeableAddress, because it was used in the past but now it's no longer being used. 2. There are no WindowedMMIOAccess or MMIOAccess classes anymore, as they made a bunch of unnecessary complexity. Instead, Windowed access is removed entirely (this was tested, but never was benchmarked), so we are left with IO access and memory access options. The memory access option is essentially mapping the PCI bus (from the chosen PCI domain), to virtual memory as-is. This means that unless needed, at any time, there is only one PCI bus being mapped, and this is changed if access to another PCI bus in the same PCI domain is needed. For now, we don't support mapping of different PCI buses from different PCI domains at the same time, because basically it's still a non-issue for most machines out there. 2. OOM-safety is increased, especially when constructing the Access object. It means that we pre-allocating any needed resources, and we try to find PCI domains (if requested to initialize memory access) after we attempt to construct the Access object, so it's possible to fail at this point "gracefully". 3. All PCI API functions are now separated into a different header file, which means only "clients" of the PCI subsystem API will need to include that header file. 4. Functional changes - we only allow now to enumerate the bus after a hardware scan. This means that the old method "enumerate_hardware" is removed, so, when initializing an Access object, the initializing function must call rescan on it to force it to find devices. This makes it possible to fail rescan, and also to defer it after construction from both OOM-safety terms and hotplug capabilities.
2021-09-07 06:08:38 -03:00
#include <Kernel/Bus/PCI/API.h>
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
#include <Kernel/Bus/PCI/Device.h>
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
#include <Kernel/Memory/TypedMapping.h>
Kernel: Add the DeviceController class in the PCI subsystem Such device is not an IRQHandler by itself, but actually a controller of many IRQ or MSI devices. The purpose of this class is to manage multiple sources of interrupts. For example, a generic ISA IDE controller controls 2 IRQ sources - 14 and 15. So, when we initialize the IDE controller, it will initialize two IDE channels (also known as PATAChannels) to utilize IRQ 14 and 15, respectively. NVMe with MSI-X support can theoretically handle up to 2048 interrupts.
2020-12-18 05:52:52 -03:00
Kernel: Use C++17 namespace style for nested PCI namespace Adjust the nested namespace formatting in PCI files to use the nicer and more consistent C++17 style.
2022-04-25 11:32:09 -03:00
namespace Kernel::PCI {
Kernel: Add the DeviceController class in the PCI subsystem Such device is not an IRQHandler by itself, but actually a controller of many IRQ or MSI devices. The purpose of this class is to manage multiple sources of interrupts. For example, a generic ISA IDE controller controls 2 IRQ sources - 14 and 15. So, when we initialize the IDE controller, it will initialize two IDE channels (also known as PATAChannels) to utilize IRQ 14 and 15, respectively. NVMe with MSI-X support can theoretically handle up to 2048 interrupts.
2020-12-18 05:52:52 -03:00
Kernel/PCI: Hold a reference to DeviceIdentifier in the Device class There are now 2 separate classes for almost the same object type: - EnumerableDeviceIdentifier, which is used in the enumeration code for all PCI host controller classes. This is allowed to be moved and copied, as it doesn't support ref-counting. - DeviceIdentifier, which inherits from EnumerableDeviceIdentifier. This class uses ref-counting, and is not allowed to be copied. It has a spinlock member in its structure to allow safely executing complicated IO sequences on a PCI device and its space configuration. There's a static method that allows a quick conversion from EnumerableDeviceIdentifier to DeviceIdentifier while creating a NonnullRefPtr out of it. The reason for doing this is for the sake of integrity and reliablity of the system in 2 places: - Ensure that "complicated" tasks that rely on manipulating PCI device registers are done in a safe manner. For example, determining a PCI BAR space size requires multiple read and writes to the same register, and if another CPU tries to do something else with our selected register, then the result will be a catastrophe. - Allow the PCI API to have a united form around a shared object which actually holds much more data than the PCI::Address structure. This is fundamental if we want to do certain types of optimizations, and be able to support more features of the PCI bus in the foreseeable future. This patch already has several implications: - All PCI::Device(s) hold a reference to a DeviceIdentifier structure being given originally from the PCI::Access singleton. This means that all instances of DeviceIdentifier structures are located in one place, and all references are pointing to that location. This ensures that locking the operation spinlock will take effect in all the appropriate places. - We no longer support adding PCI host controllers and then immediately allow for enumerating it with a lambda function. It was found that this method is extremely broken and too much complicated to work reliably with the new paradigm being introduced in this patch. This means that for Volume Management Devices (Intel VMD devices), we simply first enumerate the PCI bus for such devices in the storage code, and if we find a device, we attach it in the PCI::Access method which will scan for devices behind that bridge and will add new DeviceIdentifier(s) objects to its internal Vector. Afterwards, we just continue as usual with scanning for actual storage controllers, so we will find a corresponding NVMe controllers if there were any behind that VMD bridge.
2022-02-10 13:33:13 -03:00
Device::Device(DeviceIdentifier const& pci_identifier)
: m_pci_identifier(pci_identifier)
Kernel: Add the DeviceController class in the PCI subsystem Such device is not an IRQHandler by itself, but actually a controller of many IRQ or MSI devices. The purpose of this class is to manage multiple sources of interrupts. For example, a generic ISA IDE controller controls 2 IRQ sources - 14 and 15. So, when we initialize the IDE controller, it will initialize two IDE channels (also known as PATAChannels) to utilize IRQ 14 and 15, respectively. NVMe with MSI-X support can theoretically handle up to 2048 interrupts.
2020-12-18 05:52:52 -03:00
{
Kernel: Add MSIxInfo struct to PCI DeviceIdentifier Add a struct named MSIxInfo that stores all the relevant MSIx information as a part of PCI DeviceIdentifier struct. Populate the MSIx struct during the PCI device init. As the DeviceIdentifier struct need to populate MSIx info, don't mark DeviceIdentifier as const in the PCI::Device class.
2023-04-28 10:16:20 -03:00
m_pci_identifier->initialize();
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
m_interrupt_range.m_start_irq = m_pci_identifier->interrupt_line().value();
m_interrupt_range.m_irq_count = 1;
Kernel: Add the DeviceController class in the PCI subsystem Such device is not an IRQHandler by itself, but actually a controller of many IRQ or MSI devices. The purpose of this class is to manage multiple sources of interrupts. For example, a generic ISA IDE controller controls 2 IRQ sources - 14 and 15. So, when we initialize the IDE controller, it will initialize two IDE channels (also known as PATAChannels) to utilize IRQ 14 and 15, respectively. NVMe with MSI-X support can theoretically handle up to 2048 interrupts.
2020-12-18 05:52:52 -03:00
}
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
bool Device::is_msi_capable() const
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel: Use PCIDeviceIdentifier is_msi_capable() to retrieve MSI status Instead of iterating through the capabilities, use the is_msi_capable() API from the PCIDeviceIdentifier class that belongs to the device.
2023-05-08 16:26:55 -03:00
return m_pci_identifier->is_msi_capable();
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
bool Device::is_msix_capable() const
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel: Use PCIIdentifier is_msix_capable API to retrieve MSIx status Instead of iterating through the capabilities, use the is_msix_capable() API from the PCIIdentifier class that belongs to the device.
2023-04-29 14:23:14 -03:00
return m_pci_identifier->is_msix_capable();
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
void Device::enable_pin_based_interrupts() const
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel/PCI: Hold a reference to DeviceIdentifier in the Device class There are now 2 separate classes for almost the same object type: - EnumerableDeviceIdentifier, which is used in the enumeration code for all PCI host controller classes. This is allowed to be moved and copied, as it doesn't support ref-counting. - DeviceIdentifier, which inherits from EnumerableDeviceIdentifier. This class uses ref-counting, and is not allowed to be copied. It has a spinlock member in its structure to allow safely executing complicated IO sequences on a PCI device and its space configuration. There's a static method that allows a quick conversion from EnumerableDeviceIdentifier to DeviceIdentifier while creating a NonnullRefPtr out of it. The reason for doing this is for the sake of integrity and reliablity of the system in 2 places: - Ensure that "complicated" tasks that rely on manipulating PCI device registers are done in a safe manner. For example, determining a PCI BAR space size requires multiple read and writes to the same register, and if another CPU tries to do something else with our selected register, then the result will be a catastrophe. - Allow the PCI API to have a united form around a shared object which actually holds much more data than the PCI::Address structure. This is fundamental if we want to do certain types of optimizations, and be able to support more features of the PCI bus in the foreseeable future. This patch already has several implications: - All PCI::Device(s) hold a reference to a DeviceIdentifier structure being given originally from the PCI::Access singleton. This means that all instances of DeviceIdentifier structures are located in one place, and all references are pointing to that location. This ensures that locking the operation spinlock will take effect in all the appropriate places. - We no longer support adding PCI host controllers and then immediately allow for enumerating it with a lambda function. It was found that this method is extremely broken and too much complicated to work reliably with the new paradigm being introduced in this patch. This means that for Volume Management Devices (Intel VMD devices), we simply first enumerate the PCI bus for such devices in the storage code, and if we find a device, we attach it in the PCI::Access method which will scan for devices behind that bridge and will add new DeviceIdentifier(s) objects to its internal Vector. Afterwards, we just continue as usual with scanning for actual storage controllers, so we will find a corresponding NVMe controllers if there were any behind that VMD bridge.
2022-02-10 13:33:13 -03:00
PCI::enable_interrupt_line(m_pci_identifier);
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
void Device::disable_pin_based_interrupts() const
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel/PCI: Hold a reference to DeviceIdentifier in the Device class There are now 2 separate classes for almost the same object type: - EnumerableDeviceIdentifier, which is used in the enumeration code for all PCI host controller classes. This is allowed to be moved and copied, as it doesn't support ref-counting. - DeviceIdentifier, which inherits from EnumerableDeviceIdentifier. This class uses ref-counting, and is not allowed to be copied. It has a spinlock member in its structure to allow safely executing complicated IO sequences on a PCI device and its space configuration. There's a static method that allows a quick conversion from EnumerableDeviceIdentifier to DeviceIdentifier while creating a NonnullRefPtr out of it. The reason for doing this is for the sake of integrity and reliablity of the system in 2 places: - Ensure that "complicated" tasks that rely on manipulating PCI device registers are done in a safe manner. For example, determining a PCI BAR space size requires multiple read and writes to the same register, and if another CPU tries to do something else with our selected register, then the result will be a catastrophe. - Allow the PCI API to have a united form around a shared object which actually holds much more data than the PCI::Address structure. This is fundamental if we want to do certain types of optimizations, and be able to support more features of the PCI bus in the foreseeable future. This patch already has several implications: - All PCI::Device(s) hold a reference to a DeviceIdentifier structure being given originally from the PCI::Access singleton. This means that all instances of DeviceIdentifier structures are located in one place, and all references are pointing to that location. This ensures that locking the operation spinlock will take effect in all the appropriate places. - We no longer support adding PCI host controllers and then immediately allow for enumerating it with a lambda function. It was found that this method is extremely broken and too much complicated to work reliably with the new paradigm being introduced in this patch. This means that for Volume Management Devices (Intel VMD devices), we simply first enumerate the PCI bus for such devices in the storage code, and if we find a device, we attach it in the PCI::Access method which will scan for devices behind that bridge and will add new DeviceIdentifier(s) objects to its internal Vector. Afterwards, we just continue as usual with scanning for actual storage controllers, so we will find a corresponding NVMe controllers if there were any behind that VMD bridge.
2022-02-10 13:33:13 -03:00
PCI::disable_interrupt_line(m_pci_identifier);
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
void Device::enable_message_signalled_interrupts()
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel: Implement {enable,disable}_msi interrupts in PCI Device Implement enabling and disabling MSI interrupts for a PCI device. Removes two more TODO()s from PCI::Device.cpp :^)
2023-05-08 16:28:28 -03:00
for (auto& capability : m_pci_identifier->capabilities()) {
if (capability.id().value() == PCI::Capabilities::ID::MSI)
capability.write16(msi_control_offset, capability.read16(msi_control_offset) | msi_control_enable);
}
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
void Device::disable_message_signalled_interrupts()
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel: Implement {enable,disable}_msi interrupts in PCI Device Implement enabling and disabling MSI interrupts for a PCI device. Removes two more TODO()s from PCI::Device.cpp :^)
2023-05-08 16:28:28 -03:00
for (auto& capability : m_pci_identifier->capabilities()) {
if (capability.id().value() == PCI::Capabilities::ID::MSI)
capability.write16(msi_control_offset, capability.read16(msi_control_offset) & ~(msi_control_enable));
}
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Implement {enable,disable}_msix interrupts in PCI Device Implement enabling and disabling MSIx interrupts for a PCI device. Removes two TODO()s from PCI::Device.cpp :^)
2023-04-29 14:09:49 -03:00
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
void Device::enable_extended_message_signalled_interrupts()
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel: Implement {enable,disable}_msix interrupts in PCI Device Implement enabling and disabling MSIx interrupts for a PCI device. Removes two TODO()s from PCI::Device.cpp :^)
2023-04-29 14:09:49 -03:00
for (auto& capability : m_pci_identifier->capabilities()) {
if (capability.id().value() == PCI::Capabilities::ID::MSIX)
capability.write16(msi_control_offset, capability.read16(msi_control_offset) | msix_control_enable);
}
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Implement {enable,disable}_msix interrupts in PCI Device Implement enabling and disabling MSIx interrupts for a PCI device. Removes two TODO()s from PCI::Device.cpp :^)
2023-04-29 14:09:49 -03:00
Kernel: Rename PCI::DeviceController => PCI::Device Now that the old PCI::Device was removed, we can complete the PCI changes by making the PCI::DeviceController to be named PCI::Device. Really the entire purpose and the distinction between the two was about interrupts, but since this is no longer a problem, just rename it to simplify things further.
2021-08-21 00:58:43 -03:00
void Device::disable_extended_message_signalled_interrupts()
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
{
Kernel: Implement {enable,disable}_msix interrupts in PCI Device Implement enabling and disabling MSIx interrupts for a PCI device. Removes two TODO()s from PCI::Device.cpp :^)
2023-04-29 14:09:49 -03:00
for (auto& capability : m_pci_identifier->capabilities()) {
if (capability.id().value() == PCI::Capabilities::ID::MSIX)
capability.write16(msi_control_offset, capability.read16(msi_control_offset) & ~(msix_control_enable));
}
Kernel: Add various methods to handle interrupts in the PCI subsystem For now, we only are able to enable or disable pin based interrupts. Later, when implemented, we could utilize MSI & MSI-X interrupts.
2020-12-18 15:27:55 -03:00
}
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
PCI::InterruptType Device::get_interrupt_type()
{
return m_interrupt_range.m_type;
}
// Reserve `numbers_of_irqs` for this device. Returns the interrupt type
// that was reserved. It is a noop for pin based interrupts as there
// is nothing left to do. The second parameter `msi` is used by the
// driver to indicate its intent to use message signalled interrupts.
// MSI(x) is preferred over MSI if the device supports both.
ErrorOr<InterruptType> Device::reserve_irqs(u8 number_of_irqs, bool msi)
{
// Let us not allow partial allocation of IRQs for MSIx.
if (msi && is_msix_capable()) {
m_interrupt_range.m_start_irq = TRY(reserve_interrupt_handlers(number_of_irqs));
m_interrupt_range.m_irq_count = number_of_irqs;
m_interrupt_range.m_type = InterruptType::MSIX;
// If MSIx is available, disable the pin based interrupts
disable_pin_based_interrupts();
enable_extended_message_signalled_interrupts();
} else if (msi && is_msi_capable()) {
Kernel: Add MSI support in PCI Device Extend reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to add MSI support in PCI device. The current changes only implement single MSI message support. TODOs have been added to support Multiple MSI Message (MME) support in the future.
2023-05-08 16:29:37 -03:00
// TODO: Add MME support. Fallback to pin-based until this support is added.
if (number_of_irqs > 1)
return m_interrupt_range.m_type;
m_interrupt_range.m_start_irq = TRY(reserve_interrupt_handlers(number_of_irqs));
m_interrupt_range.m_irq_count = number_of_irqs;
m_interrupt_range.m_type = InterruptType::MSI;
disable_pin_based_interrupts();
enable_message_signalled_interrupts();
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
}
return m_interrupt_range.m_type;
}
PhysicalAddress Device::msix_table_entry_address(u8 irq)
{
auto index = static_cast<int>(irq) - m_interrupt_range.m_start_irq;
VERIFY(index < m_interrupt_range.m_irq_count);
VERIFY(index >= 0);
auto table_bar_ptr = PCI::get_BAR(device_identifier(), static_cast<PCI::HeaderType0BaseRegister>(m_pci_identifier->get_msix_table_bar())) & PCI::bar_address_mask;
auto table_offset = m_pci_identifier->get_msix_table_offset();
return PhysicalAddress(table_bar_ptr + table_offset + (index * 16));
}
// This function is used to allocate an irq at an index and returns
// the actual IRQ that was programmed at that index. This function is
// mainly useful for MSI/MSIx based interrupt mechanism where the driver
// needs to program. If the PCI device doesn't support MSIx interrupts, then
// this function will just return the irq used for pin based interrupt.
ErrorOr<u8> Device::allocate_irq(u8 index)
{
if (Checked<u8>::addition_would_overflow(m_interrupt_range.m_start_irq, index))
return Error::from_errno(EINVAL);
if ((m_interrupt_range.m_type == InterruptType::MSIX) && is_msix_capable()) {
auto entry_ptr = TRY(Memory::map_typed_writable<MSIxTableEntry volatile>(msix_table_entry_address(index + m_interrupt_range.m_start_irq)));
entry_ptr->data = msi_data_register(m_interrupt_range.m_start_irq + index, false, false);
// TODO: we map all the IRQs to cpu 0 by default. We could attach
// cpu affinity in the future where specific LAPIC id could be used.
u64 addr = msi_address_register(0, false, false);
entry_ptr->address_low = addr & 0xffffffff;
entry_ptr->address_high = addr >> 32;
u32 vector_ctrl = msix_vector_control_register(entry_ptr->vector_control, true);
entry_ptr->vector_control = vector_ctrl;
return m_interrupt_range.m_start_irq + index;
} else if ((m_interrupt_range.m_type == InterruptType::MSI) && is_msi_capable()) {
Kernel: Add MSI support in PCI Device Extend reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to add MSI support in PCI device. The current changes only implement single MSI message support. TODOs have been added to support Multiple MSI Message (MME) support in the future.
2023-05-08 16:29:37 -03:00
// TODO: Add MME support.
if (index > 0)
return Error::from_errno(EINVAL);
auto data = msi_data_register(m_interrupt_range.m_start_irq + index, false, false);
auto addr = msi_address_register(0, false, false);
for (auto& capability : m_pci_identifier->capabilities()) {
if (capability.id().value() == PCI::Capabilities::ID::MSI) {
capability.write32(msi_address_low_offset, addr & 0xffffffff);
if (!m_pci_identifier->is_msi_64bit_address_format()) {
capability.write16(msi_address_high_or_data_offset, data);
break;
}
capability.write32(msi_address_high_or_data_offset, addr >> 32);
capability.write16(msi_data_offset, data);
}
}
return m_interrupt_range.m_start_irq + index;
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
}
// For pin based interrupts, we share the IRQ.
return m_interrupt_range.m_start_irq;
}
void Device::enable_interrupt(u8 irq)
{
if ((m_interrupt_range.m_type == InterruptType::MSIX) && is_msix_capable()) {
auto entry = Memory::map_typed_writable<MSIxTableEntry volatile>(PhysicalAddress(msix_table_entry_address(irq)));
if (entry.is_error()) {
dmesgln_pci(*this, "Unable to map the MSIx table area");
return;
}
auto entry_ptr = entry.release_value();
u32 vector_ctrl = msix_vector_control_register(entry_ptr->vector_control, false);
entry_ptr->vector_control = vector_ctrl;
} else if ((m_interrupt_range.m_type == InterruptType::MSI) && is_msi_capable()) {
Kernel: Add MSI support in PCI Device Extend reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to add MSI support in PCI device. The current changes only implement single MSI message support. TODOs have been added to support Multiple MSI Message (MME) support in the future.
2023-05-08 16:29:37 -03:00
enable_message_signalled_interrupts();
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
}
}
void Device::disable_interrupt(u8 irq)
{
if ((m_interrupt_range.m_type == InterruptType::MSIX) && is_msix_capable()) {
auto entry = Memory::map_typed_writable<MSIxTableEntry volatile>(PhysicalAddress(msix_table_entry_address(irq)));
if (entry.is_error()) {
dmesgln_pci(*this, "Unable to map the MSIx table area");
return;
}
auto entry_ptr = entry.release_value();
u32 vector_ctrl = msix_vector_control_register(entry_ptr->vector_control, true);
entry_ptr->vector_control = vector_ctrl;
} else if ((m_interrupt_range.m_type == InterruptType::MSI) && is_msi_capable()) {
Kernel: Add MSI support in PCI Device Extend reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to add MSI support in PCI device. The current changes only implement single MSI message support. TODOs have been added to support Multiple MSI Message (MME) support in the future.
2023-05-08 16:29:37 -03:00
disable_message_signalled_interrupts();
Kernel: Add APIs to PCI Device to use MSI(x) Add reserve_irqs, allocate_irq, enable_interrupt and disable_interrupt API to a PCI device. reserve_irqs() can be used by a device driver that would like to reserve irqs for MSI(x) interrupts. The API returns the type of IRQ that was reserved by the PCI device. If the PCI device does not support MSI(x), then it is a noop. allocate_irq() API can be used to allocate an IRQ at an index. For MSIx the driver needs to map the vector table into the memory and add the corresponding IRQ at the given index. This API will return the actual IRQ that was used so that the driver can use it create interrupt handler for that IRQ. {enable, disable}_interrupt API is used to enable or disable a particular IRQ at the given index. It is a noop for pin-based interrupts. This could be used by IRQHandler to enable or disable an interrupt.
2023-05-05 09:38:46 -03:00
}
}
Kernel: Add the DeviceController class in the PCI subsystem Such device is not an IRQHandler by itself, but actually a controller of many IRQ or MSI devices. The purpose of this class is to manage multiple sources of interrupts. For example, a generic ISA IDE controller controls 2 IRQ sources - 14 and 15. So, when we initialize the IDE controller, it will initialize two IDE channels (also known as PATAChannels) to utilize IRQ 14 and 15, respectively. NVMe with MSI-X support can theoretically handle up to 2048 interrupts.
2020-12-18 05:52:52 -03:00
}
Reference in a new issue Copy permalink