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

94 lines
4.1 KiB
C++
Raw Normal View History

Kernel/PCI: Split host bridge code from the Access singleton Two classes are added - HostBridge and MemoryBackedHostBridge, which both derive from HostController class. This allows the kernel to map different busses from different PCI domains in the same time. Each HostController implementation doesn't take the Address object to address PCI devices but instead we take distinct numbers of the PCI bus, device and function as it allows us to specify arbitrary PCI domains in the Address structure and still to get the correct PCI devices. This also matches the hardware behavior of PCI domains - the host bridge merely takes memory operations or IO operations and translates them to addressing of three components - PCI bus, device and function. These changes also greatly simplify how enumeration of Host Bridges work now - scanning of the hardware depends on what the Host bridges can do for us, so in case we have multiple host bridges that expose a memory mapped region or IO ports to access PCI configuration space, we simply let the code of the host bridge to figure out how to fetch data for us. Another semantical change is that a PCI domain structure is no longer attached to a PhysicalAddress, so even in the case that the machine doesn't implement PCI domains, we still treat that machine to contain 1 PCI domain to treat that one host bridge in the same way, like with a machine with one or more PCI domains.
2022-01-07 09:10:44 -03:00
/*
* Copyright (c) 2022, Liav A. <liavalb@hotmail.co.il>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <AK/ByteReader.h>
#include <Kernel/Bus/PCI/Access.h>
#include <Kernel/Bus/PCI/Controller/MemoryBackedHostBridge.h>
namespace Kernel::PCI {
NonnullOwnPtr<MemoryBackedHostBridge> MemoryBackedHostBridge::must_create(Domain const& domain, PhysicalAddress start_address)
{
return adopt_own_if_nonnull(new (nothrow) MemoryBackedHostBridge(domain, start_address)).release_nonnull();
}
MemoryBackedHostBridge::MemoryBackedHostBridge(PCI::Domain const& domain, PhysicalAddress start_address)
Kernel/PCI: Move IO based HostBridge code to x86 arch-specific directory The simple PCI::HostBridge class implements access to the PCI configuration space by using x86 IO instructions. Therefore, it should be put in the Arch/x86/PCI directory so it can be easily omitted for non-x86 builds.
2022-09-02 07:41:48 -03:00
: HostController(domain)
Kernel/PCI: Split host bridge code from the Access singleton Two classes are added - HostBridge and MemoryBackedHostBridge, which both derive from HostController class. This allows the kernel to map different busses from different PCI domains in the same time. Each HostController implementation doesn't take the Address object to address PCI devices but instead we take distinct numbers of the PCI bus, device and function as it allows us to specify arbitrary PCI domains in the Address structure and still to get the correct PCI devices. This also matches the hardware behavior of PCI domains - the host bridge merely takes memory operations or IO operations and translates them to addressing of three components - PCI bus, device and function. These changes also greatly simplify how enumeration of Host Bridges work now - scanning of the hardware depends on what the Host bridges can do for us, so in case we have multiple host bridges that expose a memory mapped region or IO ports to access PCI configuration space, we simply let the code of the host bridge to figure out how to fetch data for us. Another semantical change is that a PCI domain structure is no longer attached to a PhysicalAddress, so even in the case that the machine doesn't implement PCI domains, we still treat that machine to contain 1 PCI domain to treat that one host bridge in the same way, like with a machine with one or more PCI domains.
2022-01-07 09:10:44 -03:00
, m_start_address(start_address)
{
}
u8 MemoryBackedHostBridge::read8_field(BusNumber bus, DeviceNumber device, FunctionNumber function, u32 field)
{
VERIFY(Access::the().access_lock().is_locked());
VERIFY(field <= 0xfff);
Everywhere: Run clang-format
2022-04-01 14:58:27 -03:00
return *((u8 volatile*)(get_device_configuration_memory_mapped_space(bus, device, function).get() + (field & 0xfff)));
Kernel/PCI: Split host bridge code from the Access singleton Two classes are added - HostBridge and MemoryBackedHostBridge, which both derive from HostController class. This allows the kernel to map different busses from different PCI domains in the same time. Each HostController implementation doesn't take the Address object to address PCI devices but instead we take distinct numbers of the PCI bus, device and function as it allows us to specify arbitrary PCI domains in the Address structure and still to get the correct PCI devices. This also matches the hardware behavior of PCI domains - the host bridge merely takes memory operations or IO operations and translates them to addressing of three components - PCI bus, device and function. These changes also greatly simplify how enumeration of Host Bridges work now - scanning of the hardware depends on what the Host bridges can do for us, so in case we have multiple host bridges that expose a memory mapped region or IO ports to access PCI configuration space, we simply let the code of the host bridge to figure out how to fetch data for us. Another semantical change is that a PCI domain structure is no longer attached to a PhysicalAddress, so even in the case that the machine doesn't implement PCI domains, we still treat that machine to contain 1 PCI domain to treat that one host bridge in the same way, like with a machine with one or more PCI domains.
2022-01-07 09:10:44 -03:00
}
u16 MemoryBackedHostBridge::read16_field(BusNumber bus, DeviceNumber device, FunctionNumber function, u32 field)
{
VERIFY(Access::the().access_lock().is_locked());
VERIFY(field < 0xfff);
u16 data = 0;
ByteReader::load<u16>(get_device_configuration_memory_mapped_space(bus, device, function).offset(field & 0xfff).as_ptr(), data);
return data;
}
u32 MemoryBackedHostBridge::read32_field(BusNumber bus, DeviceNumber device, FunctionNumber function, u32 field)
{
VERIFY(Access::the().access_lock().is_locked());
VERIFY(field <= 0xffc);
u32 data = 0;
ByteReader::load<u32>(get_device_configuration_memory_mapped_space(bus, device, function).offset(field & 0xfff).as_ptr(), data);
return data;
}
void MemoryBackedHostBridge::write8_field(BusNumber bus, DeviceNumber device, FunctionNumber function, u32 field, u8 value)
{
VERIFY(Access::the().access_lock().is_locked());
VERIFY(field <= 0xfff);
Everywhere: Run clang-format
2022-04-01 14:58:27 -03:00
*((u8 volatile*)(get_device_configuration_memory_mapped_space(bus, device, function).get() + (field & 0xfff))) = value;
Kernel/PCI: Split host bridge code from the Access singleton Two classes are added - HostBridge and MemoryBackedHostBridge, which both derive from HostController class. This allows the kernel to map different busses from different PCI domains in the same time. Each HostController implementation doesn't take the Address object to address PCI devices but instead we take distinct numbers of the PCI bus, device and function as it allows us to specify arbitrary PCI domains in the Address structure and still to get the correct PCI devices. This also matches the hardware behavior of PCI domains - the host bridge merely takes memory operations or IO operations and translates them to addressing of three components - PCI bus, device and function. These changes also greatly simplify how enumeration of Host Bridges work now - scanning of the hardware depends on what the Host bridges can do for us, so in case we have multiple host bridges that expose a memory mapped region or IO ports to access PCI configuration space, we simply let the code of the host bridge to figure out how to fetch data for us. Another semantical change is that a PCI domain structure is no longer attached to a PhysicalAddress, so even in the case that the machine doesn't implement PCI domains, we still treat that machine to contain 1 PCI domain to treat that one host bridge in the same way, like with a machine with one or more PCI domains.
2022-01-07 09:10:44 -03:00
}
void MemoryBackedHostBridge::write16_field(BusNumber bus, DeviceNumber device, FunctionNumber function, u32 field, u16 value)
{
VERIFY(Access::the().access_lock().is_locked());
VERIFY(field < 0xfff);
ByteReader::store<u16>(get_device_configuration_memory_mapped_space(bus, device, function).offset(field & 0xfff).as_ptr(), value);
}
void MemoryBackedHostBridge::write32_field(BusNumber bus, DeviceNumber device, FunctionNumber function, u32 field, u32 value)
{
VERIFY(Access::the().access_lock().is_locked());
VERIFY(field <= 0xffc);
ByteReader::store<u32>(get_device_configuration_memory_mapped_space(bus, device, function).offset(field & 0xfff).as_ptr(), value);
}
void MemoryBackedHostBridge::map_bus_region(BusNumber bus)
{
VERIFY(Access::the().access_lock().is_locked());
if (m_mapped_bus == bus && m_mapped_bus_region)
return;
auto bus_base_address = determine_memory_mapped_bus_base_address(bus);
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 14:32:29 -03:00
auto region_or_error = MM.allocate_kernel_region(bus_base_address, memory_range_per_bus, "PCI ECAM"sv, Memory::Region::Access::ReadWrite);
Kernel/PCI: Split host bridge code from the Access singleton Two classes are added - HostBridge and MemoryBackedHostBridge, which both derive from HostController class. This allows the kernel to map different busses from different PCI domains in the same time. Each HostController implementation doesn't take the Address object to address PCI devices but instead we take distinct numbers of the PCI bus, device and function as it allows us to specify arbitrary PCI domains in the Address structure and still to get the correct PCI devices. This also matches the hardware behavior of PCI domains - the host bridge merely takes memory operations or IO operations and translates them to addressing of three components - PCI bus, device and function. These changes also greatly simplify how enumeration of Host Bridges work now - scanning of the hardware depends on what the Host bridges can do for us, so in case we have multiple host bridges that expose a memory mapped region or IO ports to access PCI configuration space, we simply let the code of the host bridge to figure out how to fetch data for us. Another semantical change is that a PCI domain structure is no longer attached to a PhysicalAddress, so even in the case that the machine doesn't implement PCI domains, we still treat that machine to contain 1 PCI domain to treat that one host bridge in the same way, like with a machine with one or more PCI domains.
2022-01-07 09:10:44 -03:00
// FIXME: Find a way to propagate error from here.
if (region_or_error.is_error())
VERIFY_NOT_REACHED();
m_mapped_bus_region = region_or_error.release_value();
m_mapped_bus = bus;
dbgln_if(PCI_DEBUG, "PCI: New PCI ECAM Mapped region for bus {} @ {} {}", bus, m_mapped_bus_region->vaddr(), m_mapped_bus_region->physical_page(0)->paddr());
}
VirtualAddress MemoryBackedHostBridge::get_device_configuration_memory_mapped_space(BusNumber bus, DeviceNumber device, FunctionNumber function)
{
VERIFY(Access::the().access_lock().is_locked());
map_bus_region(bus);
return m_mapped_bus_region->vaddr().offset(mmio_device_space_size * function.value() + (mmio_device_space_size * to_underlying(Limits::MaxFunctionsPerDevice)) * device.value());
}
PhysicalAddress MemoryBackedHostBridge::determine_memory_mapped_bus_base_address(BusNumber bus) const
{
auto start_bus = min(bus.value(), m_domain.start_bus());
return m_start_address.offset(memory_range_per_bus * (bus.value() - start_bus));
}
}
Reference in a new issue Copy permalink