In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Define the MSI/MSI-X APIs to be used with the Generic PCIe Controller API.
It notably adds the msi_device_setup() callback to the PCI Express
Controller API used to allocate and setup the MSI/MSI-C vectors on the
MSI message translater HW.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
In order to preserve stack, this replaces the single-bus enumeration
loop by a stack based non-recursive pcie hierarchy iteration.
Each stack entry contains a bridge bus enumeration state.
When a bridge endpoint is detected on the current bus, it is
configured and this new bus is pushed on top of the stack in
order to be enumerated at next loop.
When enumeration ends on the bus, the current bus state is
removed from the stack to continue enumeration on the previous
bus.
This enumeration affects a sequential bus number to each new
bus detected in the same order as Linux & U-Boot does.
In this hierarchy:
[0 1 2 ... 31]
| | |
EP | |
| |
[0 1 ... 31] [0 ... 31]
| | |
| EP |
| [0 ... 31]
[0 ... 31] |
| EP
EP
We will get the following BDFs enumeration order:
00:00.0 Endpoint
00:01.0 Bridge => Bus primary 0 secondary 1
01:00.0 Bridge => Bus primary 1 secondary 2
02:00.0 Endpoint
... Bus secondary 2 => subordinate 2
01:01.0 Endpoint
... Bus secondary 1 => subordinate 2
00:02.0 Bridge => Bus primary 0 secondary 3
03:00.0 Bridge => Bus primary 3 secondary 4
04:00.0 Endpoint
... Bus secondary 4 => subordinate 4
... Bus secondary 3 => subordinate 4
The gives the following primary/secondary/subordinate map:
Bus 0 [0 1 2 ... 31]
| | |
| [0:1->2] [0:3->4]
EP 00:00.0 | |
| |
Bus 1 [0 1 ... 31] Bus 3 [0 ... 31]
| | |
| EP 01:01.0 |
[1:2->2] [3:4->4]
| |
| Bus 4 [0 ... 31]
Bus 2 [0 ... 31] |
| EP 04:00.0
EP 02:00.0
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
This adds setup of Type 1 bridge endpoints in two steps, first when
endpoint is detected and secondly when enumerating the next endpoint.
First, the code configures the bus primary & secondary number and 0xff
as subordinate to redirect all PCIe messages to this bus.
Then memory & I/O base are programmed by getting the current allocation
bases.
Finally, now right away, we program the subordinate to the max bus
number under the bridge, here the same, and the memory & I/O limit,
here lower than the base.
This doesn't make the bridge totally usable, enumeration would work
bus not for nested bridges and BARs wouldn't be accessible.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
In order to prepare support for bridges enumeration, split out the
actual endpoint enumeration code out of the enumeration loop.
Pass a skip_next_func boolean to indicate if the current endpoint
is multifunction of not, to continue to next dev or next function.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
The Type 1 endpoints has 2 BARs are the same position as the Type 0
BARS 0 & 1, so reuse the generic_pcie_ctrl_type0_enumerate_bars()
for both types by passing the number of possible BARs on the endpoint.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
As suggested by Tomasz Bursztyka, it's clearer to move generic after the
domain prefix, here pcie.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
As suggested by Tomasz Bursztyka, translate is clearer than xlate in
the PCIe controller functions and callbacks names.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
This adds :
- Generic PCIe Controller layer implementing the current PCIe API
- Generic PCIe Controller in ECAM mode driver
The Generic PCIe Controller layer provides:
- Configuration space read/write
- single bus endpoint enumerations
- Endpoint I/O, MEM & MEM64 BARs allocation
- Endpoint I/O, MEM & MEM64 BARs get & translation for drivers
The Generic PCIe Controller in ECAM mode driver provides:
- Raw DT RANGES properties into usable PCIe regions
- Configuration space read/write into ECAM config space
- PCIe regions allocation & translation
The limitations are:
- No support for PCIe prefetchable regions
- No support for PCIe bus configuration (only bus0 is supported)
- No support for multiple controllers (no domain-id in BDF)
Support has been designed to initially support Root Complexes with
Root Complex Integrated Endpoint, which was designed for Embedded
Systems with internal-only PCIe Endpoints on bus 0.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
