Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Kernel/PCI/MMIOAccess.cpp

216 lines
8.2 KiB
C++
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
/*
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
* Copyright (c) 2021, Liav A. <liavalb@hotmail.co.il>
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*
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 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*/
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
#include <AK/Optional.h>
AK: Reduce header dependency graph of String.h String.h no longer pulls in StringView.h. We do this by moving a bunch of String functions out-of-line.
2020-03-23 13:45:10 +01:00
#include <AK/StringView.h>
Kernel: Pull apart CPU.h This does not add any functional changes
2021-06-21 17:34:09 +02:00
#include <Kernel/Arch/x86/InterruptDisabler.h>
Meta: Split debug defines into multiple headers. The following script was used to make these changes: #!/bin/bash set -e tmp=$(mktemp -d) echo "tmp=$tmp" find Kernel \( -name '*.cpp' -o -name '*.h' \) | sort > $tmp/Kernel.files find . \( -path ./Toolchain -prune -o -path ./Build -prune -o -path ./Kernel -prune \) -o \( -name '*.cpp' -o -name '*.h' \) -print | sort > $tmp/EverythingExceptKernel.files cat $tmp/Kernel.files | xargs grep -Eho '[A-Z0-9_]+_DEBUG' | sort | uniq > $tmp/Kernel.macros cat $tmp/EverythingExceptKernel.files | xargs grep -Eho '[A-Z0-9_]+_DEBUG' | sort | uniq > $tmp/EverythingExceptKernel.macros comm -23 $tmp/Kernel.macros $tmp/EverythingExceptKernel.macros > $tmp/Kernel.unique comm -1 $tmp/Kernel.macros $tmp/EverythingExceptKernel.macros > $tmp/EverythingExceptKernel.unique cat $tmp/Kernel.unique | awk '{ print "#cmakedefine01 "$1 }' > $tmp/Kernel.header cat $tmp/EverythingExceptKernel.unique | awk '{ print "#cmakedefine01 "$1 }' > $tmp/EverythingExceptKernel.header for macro in $(cat $tmp/Kernel.unique) do cat $tmp/Kernel.files | xargs grep -l $macro >> $tmp/Kernel.new-includes ||: done cat $tmp/Kernel.new-includes | sort > $tmp/Kernel.new-includes.sorted for macro in $(cat $tmp/EverythingExceptKernel.unique) do cat $tmp/Kernel.files | xargs grep -l $macro >> $tmp/Kernel.old-includes ||: done cat $tmp/Kernel.old-includes | sort > $tmp/Kernel.old-includes.sorted comm -23 $tmp/Kernel.new-includes.sorted $tmp/Kernel.old-includes.sorted > $tmp/Kernel.includes.new comm -13 $tmp/Kernel.new-includes.sorted $tmp/Kernel.old-includes.sorted > $tmp/Kernel.includes.old comm -12 $tmp/Kernel.new-includes.sorted $tmp/Kernel.old-includes.sorted > $tmp/Kernel.includes.mixed for file in $(cat $tmp/Kernel.includes.new) do sed -i -E 's/#include <AK\/Debug\.h>/#include <Kernel\/Debug\.h>/' $file done for file in $(cat $tmp/Kernel.includes.mixed) do echo "mixed include in $file, requires manual editing." done
2021-01-25 16:07:10 +01:00
#include <Kernel/Debug.h>
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
#include <Kernel/PCI/MMIOAccess.h>
Kernel: Move special sections into Sections.h This also removes a lot of CPU.h includes infavor for Sections.h
2021-06-22 17:40:16 +02:00
#include <Kernel/Sections.h>
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
#include <Kernel/VM/MemoryManager.h>
Kernel: Move all code into the Kernel namespace
2020-02-16 01:27:42 +01:00
namespace Kernel {
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
namespace PCI {
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
#define MEMORY_RANGE_PER_BUS (PCI_MMIO_CONFIG_SPACE_SIZE * PCI_MAX_FUNCTIONS_PER_DEVICE * PCI_MAX_DEVICES_PER_BUS)
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
u32 MMIOAccess::segment_count() const
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
return m_segments.size();
}
Kernel: Fix up various PCI-related function signatures - Make things const when they don't need to be non-const. - Don't return AK::String when it's always a string literal anyway. - Remove excessive get_ prefixes per coding style.
2020-04-08 17:09:49 +02:00
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
u8 MMIOAccess::segment_start_bus(u32 seg) const
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel: Simplify PCI::MMIOAccess segment storage Instead of nesting a bunch of heap allocations, just store them in a simple HashMap<u16, MMIOSegment>. Also fix a bunch of double hash lookups like this: ASSERT(map.contains(key)); auto thing = map.get(key).value(); They now look like this instead: auto thing = map.get(key); ASSERT(thing.has_value());
2020-04-08 17:23:20 +02:00
auto segment = m_segments.get(seg);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(segment.has_value());
Kernel: Simplify PCI::MMIOAccess segment storage Instead of nesting a bunch of heap allocations, just store them in a simple HashMap<u16, MMIOSegment>. Also fix a bunch of double hash lookups like this: ASSERT(map.contains(key)); auto thing = map.get(key).value(); They now look like this instead: auto thing = map.get(key); ASSERT(thing.has_value());
2020-04-08 17:23:20 +02:00
return segment.value().get_start_bus();
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Fix up various PCI-related function signatures - Make things const when they don't need to be non-const. - Don't return AK::String when it's always a string literal anyway. - Remove excessive get_ prefixes per coding style.
2020-04-08 17:09:49 +02:00
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
u8 MMIOAccess::segment_end_bus(u32 seg) const
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel: Simplify PCI::MMIOAccess segment storage Instead of nesting a bunch of heap allocations, just store them in a simple HashMap<u16, MMIOSegment>. Also fix a bunch of double hash lookups like this: ASSERT(map.contains(key)); auto thing = map.get(key).value(); They now look like this instead: auto thing = map.get(key); ASSERT(thing.has_value());
2020-04-08 17:23:20 +02:00
auto segment = m_segments.get(seg);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(segment.has_value());
Kernel: Simplify PCI::MMIOAccess segment storage Instead of nesting a bunch of heap allocations, just store them in a simple HashMap<u16, MMIOSegment>. Also fix a bunch of double hash lookups like this: ASSERT(map.contains(key)); auto thing = map.get(key).value(); They now look like this instead: auto thing = map.get(key); ASSERT(thing.has_value());
2020-04-08 17:23:20 +02:00
return segment.value().get_end_bus();
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel/PCI: Don't unmap determine_memory_mapped_bus_region after init This can be accessed after init via lspci.
2021-06-30 00:13:26 +01:00
PhysicalAddress MMIOAccess::determine_memory_mapped_bus_region(u32 segment, u8 bus) const
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
{
VERIFY(bus >= segment_start_bus(segment) && bus <= segment_end_bus(segment));
auto seg = m_segments.get(segment);
VERIFY(seg.has_value());
return seg.value().get_paddr().offset(MEMORY_RANGE_PER_BUS * (bus - seg.value().get_start_bus()));
}
Kernel: Slap UNMAP_AFTER_INIT on a bunch more functions We're now able to unmap 100 KiB of kernel text after init. :^)
2021-02-19 21:29:46 +01:00
UNMAP_AFTER_INIT void MMIOAccess::initialize(PhysicalAddress mcfg)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Add a bunch of debug output to accessors This was useful for debugging this issue.
2020-12-22 04:22:32 +00:00
if (!Access::is_initialized()) {
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
new MMIOAccess(mcfg);
Kernel: Convert klog() => AK::Format in PCI
2021-03-12 13:57:56 +01:00
dbgln_if(PCI_DEBUG, "PCI: MMIO access initialised.");
Kernel/PCI: Add a bunch of debug output to accessors This was useful for debugging this issue.
2020-12-22 04:22:32 +00:00
}
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Slap UNMAP_AFTER_INIT on a bunch more functions We're now able to unmap 100 KiB of kernel text after init. :^)
2021-02-19 21:29:46 +01:00
UNMAP_AFTER_INIT MMIOAccess::MMIOAccess(PhysicalAddress p_mcfg)
Kernel: Don't use references or pointers to physical addresses Now the ACPI & PCI code is more safer, because we don't use raw pointers or references to objects or data that are located in the physical address space, so an accidental dereference cannot happen easily. Instead, we use the PhysicalAddress class to represent those addresses.
2020-02-24 00:59:00 +02:00
: m_mcfg(p_mcfg)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel: Convert klog() => AK::Format in PCI
2021-03-12 13:57:56 +01:00
dmesgln("PCI: Using MMIO for PCI configuration space access");
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
Kernel: Don't use references or pointers to physical addresses Now the ACPI & PCI code is more safer, because we don't use raw pointers or references to objects or data that are located in the physical address space, so an accidental dereference cannot happen easily. Instead, we use the PhysicalAddress class to represent those addresses.
2020-02-24 00:59:00 +02:00
auto checkup_region = MM.allocate_kernel_region(p_mcfg.page_base(), (PAGE_SIZE * 2), "PCI MCFG Checkup", Region::Access::Read | Region::Access::Write);
Kernel: Convert klog() => AK::Format in PCI
2021-03-12 13:57:56 +01:00
dbgln_if(PCI_DEBUG, "PCI: Checking MCFG Table length to choose the correct mapping size");
LibBareMetal: Return FlatPtr from PhysicalAddress::offset_in_page()
2020-03-08 18:29:48 +02:00
auto* sdt = (ACPI::Structures::SDTHeader*)checkup_region->vaddr().offset(p_mcfg.offset_in_page()).as_ptr();
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
u32 length = sdt->length;
u8 revision = sdt->revision;
Kernel: Convert klog() => AK::Format in PCI
2021-03-12 13:57:56 +01:00
dbgln("PCI: MCFG, length: {}, revision: {}", length, revision);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
checkup_region->unmap();
Kernel: Assert if rounding-up-to-page-size would wrap around to 0 If we try to align a number above 0xfffff000 to the next multiple of the page size (4 KiB), it would wrap around to 0. This is most likely never what we want, so let's assert if that happens.
2021-02-14 09:57:19 +01:00
auto mcfg_region = MM.allocate_kernel_region(p_mcfg.page_base(), page_round_up(length) + PAGE_SIZE, "PCI Parsing MCFG", Region::Access::Read | Region::Access::Write);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
LibBareMetal: Return FlatPtr from PhysicalAddress::offset_in_page()
2020-03-08 18:29:48 +02:00
auto& mcfg = *(ACPI::Structures::MCFG*)mcfg_region->vaddr().offset(p_mcfg.offset_in_page()).as_ptr();
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: Checking MCFG @ {}, {}", VirtualAddress(&mcfg), PhysicalAddress(p_mcfg.get()));
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
PCI: Adopt changes in ACPI definitions file
2020-02-28 22:31:58 +02:00
for (u32 index = 0; index < ((mcfg.header.length - sizeof(ACPI::Structures::MCFG)) / sizeof(ACPI::Structures::PCI_MMIO_Descriptor)); index++) {
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
u8 start_bus = mcfg.descriptors[index].start_pci_bus;
u8 end_bus = mcfg.descriptors[index].end_pci_bus;
u32 lower_addr = mcfg.descriptors[index].base_addr;
Kernel: Simplify PCI::MMIOAccess segment storage Instead of nesting a bunch of heap allocations, just store them in a simple HashMap<u16, MMIOSegment>. Also fix a bunch of double hash lookups like this: ASSERT(map.contains(key)); auto thing = map.get(key).value(); They now look like this instead: auto thing = map.get(key); ASSERT(thing.has_value());
2020-04-08 17:23:20 +02:00
m_segments.set(index, { PhysicalAddress(lower_addr), start_bus, end_bus });
Kernel: Convert klog() => AK::Format in PCI
2021-03-12 13:57:56 +01:00
dmesgln("PCI: New PCI segment @ {}, PCI buses ({}-{})", PhysicalAddress { lower_addr }, start_bus, end_bus);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
mcfg_region->unmap();
Kernel: Convert klog() => AK::Format in PCI
2021-03-12 13:57:56 +01:00
dmesgln("PCI: MMIO segments: {}", m_segments.size());
Kernel: Keep records of PCI::Address & PCI::ID pairs for enumeration
2020-04-10 20:25:03 +03:00
Kernel: Fixing PCI MMIO access mechanism During initialization of PCI MMIO access mechanism we ensure that we have an allocation from the kernel virtual address space that cannot be taken by other components in the OS. Also, now we ensure that interrupts are disabled so mapping the region doesn't fail. In order to reduce overhead, map_device() will map the requested PCI address only if it's not mapped already. The run script has been changed so now we can boot a Q35 machine, that supports PCI ECAM. To ensure we will be able to load the machine, a PIIX3 IDE controller was added to the Q35 machine configuration in the run script. An AHCI controller was added to the i440fx machine configuration.
2020-01-02 15:54:32 +02:00
InterruptDisabler disabler;
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
VERIFY(m_segments.contains(0));
// Note: we need to map this region before enumerating the hardware and adding
// PCI::PhysicalID objects to the vector, because get_capabilities calls
// PCI::read16 which will need this region to be mapped.
Kernel/PCI: Keep track of the currently mapped bus in MMIO mode There is a check in map_bus_region to make sure we don't pointlessly remap the bus region if the previous mapping was for the same bus. This is tracked with `m_mapped_bus`. However, nothing was actually updating `m_mapped_bus`, and it is initialised to 0. This means that if we start with a device on bus 0, the read in data will be valid. If we map say bus 1 then bus 0 again, the map for bus 0 will now be ignored and invalid data will be read in. Fixed by updating `m_mapped_bus` with the currently mapped bus.
2021-06-29 23:29:42 +01:00
u8 start_bus = m_segments.get(0).value().get_start_bus();
m_mapped_region = MM.allocate_kernel_region(determine_memory_mapped_bus_region(0, start_bus), MEMORY_RANGE_PER_BUS, "PCI ECAM", Region::Access::Read | Region::Access::Write);
m_mapped_bus = start_bus;
dbgln_if(PCI_DEBUG, "PCI: First PCI ECAM Mapped region for starting bus {} @ {} {}", start_bus, m_mapped_region->vaddr(), m_mapped_region->physical_page(0)->paddr());
Kernel: Keep records of PCI::Address & PCI::ID pairs for enumeration
2020-04-10 20:25:03 +03:00
enumerate_hardware([&](const Address& address, ID id) {
Kernel/PCI: Create device configuration space mapping before creating a physical ID When enumerating the hardware using MMIO mode, it would attempt to create a physical ID first. To create a physical ID, it needs to retrieve the capabilities of the device. When enumerating the first device, there would be no device configuration space mappings. Access::get_capabilities_pointer calls PCI::read16, which in turn goes to MMIOAccess::read16_field. MMIOAccess::read16_field attempts to get a device configuration space and fully expects to get one. However, since this is the first device, there are none and it crashes with an m_has_value assertion failure. This fixes this by creating the device configuration space mapping before creating the physical ID. Testing with VMware Player 16.1.0.
2020-12-22 04:03:20 +00:00
m_physical_ids.append({ address, id, get_capabilities(address) });
Kernel: Keep records of PCI::Address & PCI::ID pairs for enumeration
2020-04-10 20:25:03 +03:00
});
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
void MMIOAccess::map_bus_region(u32 segment, u8 bus)
{
VERIFY(m_access_lock.is_locked());
if (m_mapped_bus == bus)
return;
m_mapped_region = MM.allocate_kernel_region(determine_memory_mapped_bus_region(segment, bus), MEMORY_RANGE_PER_BUS, "PCI ECAM", Region::Access::Read | Region::Access::Write);
Kernel/PCI: Keep track of the currently mapped bus in MMIO mode There is a check in map_bus_region to make sure we don't pointlessly remap the bus region if the previous mapping was for the same bus. This is tracked with `m_mapped_bus`. However, nothing was actually updating `m_mapped_bus`, and it is initialised to 0. This means that if we start with a device on bus 0, the read in data will be valid. If we map say bus 1 then bus 0 again, the map for bus 0 will now be ignored and invalid data will be read in. Fixed by updating `m_mapped_bus` with the currently mapped bus.
2021-06-29 23:29:42 +01:00
m_mapped_bus = bus;
dbgln_if(PCI_DEBUG, "PCI: New PCI ECAM Mapped region for bus {} @ {} {}", bus, m_mapped_region->vaddr(), m_mapped_region->physical_page(0)->paddr());
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
}
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
VirtualAddress MMIOAccess::get_device_configuration_space(Address address)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
VERIFY(m_access_lock.is_locked());
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: Getting device configuration space for {}", address);
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
map_bus_region(address.seg(), address.bus());
return m_mapped_region->vaddr().offset(PCI_MMIO_CONFIG_SPACE_SIZE * address.function() + (PCI_MMIO_CONFIG_SPACE_SIZE * PCI_MAX_FUNCTIONS_PER_DEVICE) * address.device());
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
u8 MMIOAccess::read8_field(Address address, u32 field)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
ScopedSpinLock lock(m_access_lock);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(field <= 0xfff);
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: MMIO Reading 8-bit field {:#08x} for {}", field, address);
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
return *((volatile u8*)(get_device_configuration_space(address).get() + (field & 0xfff)));
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
u16 MMIOAccess::read16_field(Address address, u32 field)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
ScopedSpinLock lock(m_access_lock);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(field < 0xfff);
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: MMIO Reading 16-bit field {:#08x} for {}", field, address);
Kernel/PCI + CPU: Allow to access unaligned data
2021-04-04 22:13:20 +03:00
u16 data = 0;
read_possibly_unaligned_data<u16>(get_device_configuration_space(address).offset(field & 0xfff).as_ptr(), data);
return data;
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
u32 MMIOAccess::read32_field(Address address, u32 field)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
ScopedSpinLock lock(m_access_lock);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(field <= 0xffc);
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: MMIO Reading 32-bit field {:#08x} for {}", field, address);
Kernel/PCI + CPU: Allow to access unaligned data
2021-04-04 22:13:20 +03:00
u32 data = 0;
read_possibly_unaligned_data<u32>(get_device_configuration_space(address).offset(field & 0xfff).as_ptr(), data);
return data;
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
void MMIOAccess::write8_field(Address address, u32 field, u8 value)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
ScopedSpinLock lock(m_access_lock);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(field <= 0xfff);
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: MMIO Writing 8-bit field {:#08x}, value={:#02x} for {}", field, value, address);
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
*((volatile u8*)(get_device_configuration_space(address).get() + (field & 0xfff))) = value;
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
void MMIOAccess::write16_field(Address address, u32 field, u16 value)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
ScopedSpinLock lock(m_access_lock);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(field < 0xfff);
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: MMIO Writing 16-bit field {:#08x}, value={:#02x} for {}", field, value, address);
Kernel/PCI + CPU: Allow to access unaligned data
2021-04-04 22:13:20 +03:00
write_possibly_unaligned_data<u16>(get_device_configuration_space(address).offset(field & 0xfff).as_ptr(), value);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
void MMIOAccess::write32_field(Address address, u32 field, u32 value)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
ScopedSpinLock lock(m_access_lock);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(field <= 0xffc);
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: MMIO Writing 32-bit field {:#08x}, value={:#02x} for {}", field, value, address);
Kernel/PCI + CPU: Allow to access unaligned data
2021-04-04 22:13:20 +03:00
write_possibly_unaligned_data<u32>(get_device_configuration_space(address).offset(field & 0xfff).as_ptr(), value);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
Kernel: Keep records of PCI::Address & PCI::ID pairs for enumeration
2020-04-10 20:25:03 +03:00
void MMIOAccess::enumerate_hardware(Function<void(Address, ID)> callback)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
for (u16 seg = 0; seg < m_segments.size(); seg++) {
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(PCI_DEBUG, "PCI: Enumerating Memory mapped IO segment {}", seg);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
// Single PCI host controller.
Kernel: Map PCI devices only once during boot Instead of mapping a 4KB region to access device configuration space each time we call one of the PCI helpers, just map them once during the boot process. Then, if we request to access one of those devices, we can ask the PCI subsystem to give us the virtual address where the device's configuration space is mapped.
2020-10-31 22:24:01 +02:00
if ((early_read8_field(Address(seg), PCI_HEADER_TYPE) & 0x80) == 0) {
Kernel: Fix PCI bridge enumeration The enumeration code is already enumerating all buses, recursively enumerating bridges (which are buses) makes devices on bridges being enumerated multiple times. Also, the PCI code was incorrectly mixing up terminology; let's settle down on bus, device and function because ever since PCIe came along "slots" isn't really a thing anymore.
2021-01-31 12:03:23 +01:00
enumerate_bus(-1, 0, callback, true);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
return;
}
// Multiple PCI host controllers.
for (u8 function = 0; function < 8; ++function) {
Kernel: Map PCI devices only once during boot Instead of mapping a 4KB region to access device configuration space each time we call one of the PCI helpers, just map them once during the boot process. Then, if we request to access one of those devices, we can ask the PCI subsystem to give us the virtual address where the device's configuration space is mapped.
2020-10-31 22:24:01 +02:00
if (early_read16_field(Address(seg, 0, 0, function), PCI_VENDOR_ID) == PCI_NONE)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
break;
Kernel: Fix PCI bridge enumeration The enumeration code is already enumerating all buses, recursively enumerating bridges (which are buses) makes devices on bridges being enumerated multiple times. Also, the PCI code was incorrectly mixing up terminology; let's settle down on bus, device and function because ever since PCIe came along "slots" isn't really a thing anymore.
2021-01-31 12:03:23 +01:00
enumerate_bus(-1, function, callback, false);
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
}
}
}
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
MMIOAccess::MMIOSegment::MMIOSegment(PhysicalAddress segment_base_addr, u8 start_bus, u8 end_bus)
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
: m_base_addr(segment_base_addr)
, m_start_bus(start_bus)
, m_end_bus(end_bus)
{
}
Kernel: Fix up various PCI-related function signatures - Make things const when they don't need to be non-const. - Don't return AK::String when it's always a string literal anyway. - Remove excessive get_ prefixes per coding style.
2020-04-08 17:09:49 +02:00
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
u8 MMIOAccess::MMIOSegment::get_start_bus() const
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
return m_start_bus;
}
Kernel: Fix up various PCI-related function signatures - Make things const when they don't need to be non-const. - Don't return AK::String when it's always a string literal anyway. - Remove excessive get_ prefixes per coding style.
2020-04-08 17:09:49 +02:00
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
u8 MMIOAccess::MMIOSegment::get_end_bus() const
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
return m_end_bus;
}
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
size_t MMIOAccess::MMIOSegment::get_size() const
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
return (PCI_MMIO_CONFIG_SPACE_SIZE * PCI_MAX_FUNCTIONS_PER_DEVICE * PCI_MAX_DEVICES_PER_BUS * (get_end_bus() - get_start_bus()));
}
Kernel/PCI: Introduce a new ECAM access mechanism Now the kernel supports 2 ECAM access methods. MMIOAccess was renamed to WindowedMMIOAccess and is what we had until now - each device that is detected on boot is assigned to a memory-mapped window, so IO operations on multiple devices can occur simultaneously due to creating multiple virtual mappings, hence the name is a memory-mapped window. This commit adds a new class called MMIOAccess (not to be confused with the old MMIOAccess class). This class creates one memory-mapped window. On each IO operation on a configuration space of a device, it maps the requested PCI bus region to that window. Therefore it holds a SpinLock during the operation to ensure that no other PCI bus region was mapped during the call. A user can choose to either use PCI ECAM with memory-mapped window for each device, or for an entire bus. By default, the kernel prefers to map the entire PCI bus region.
2021-04-03 16:46:04 +03:00
PhysicalAddress MMIOAccess::MMIOSegment::get_paddr() const
Kernel: Create support for PCI ECAM The new PCI subsystem is initialized during runtime. PCI::Initializer is supposed to be called during early boot, to perform a few tests, and initialize the proper configuration space access mechanism. Kernel boot parameters can be specified by a user to determine what tests will occur, to aid debugging on problematic machines. After that, PCI::Initializer should be dismissed. PCI::IOAccess is a class that is derived from PCI::Access class and implements PCI configuration space access mechanism via x86 IO ports. PCI::MMIOAccess is a class that is derived from PCI::Access and implements PCI configurtaion space access mechanism via memory access. The new PCI subsystem also supports determination of IO/MMIO space needed by a device by checking a given BAR. In addition, Every device or component that use the PCI subsystem has changed to match the last changes.
2019-12-31 13:04:30 +02:00
{
return m_base_addr;
}
Kernel: Move all code into the Kernel namespace
2020-02-16 01:27:42 +01:00
}
Kernel: Move PCI::MMIOSegment declaration into MMIOAccess.cpp This is only used inside PCI::MMIOAccess, no need to expose it.
2020-04-08 17:14:55 +02:00
}
Reference in a new issue Copy permalink