Move reading PCIE_CONF_CMDSTAT before actual usage. There are four
return branches before value is used.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
I/O or memory decoding should be disabled via the command register
before sizing BAR for calculation MMIO size
Signed-off-by: Najumon B.A <najumon.ba@intel.com>
This puts a ifdef guard around the inclusion of ACPICA header
file. The ACPICA module is not active unless CONFIG_ACPI is
also enabled so we should not be using that header without
CONFIG_ACPI also being enabled.
This was discovered by Coverity.
Fixes#60484
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
PCIe devices refer to interrupt nodes, but are initialized with the same
priority, making the sequence depending on the linking order. Add a new
symbol and set it to one unit after intc to ensure that the
initialization sequence is stable.
Found with:
west build -p -b qemu_cortex_a53 \
samples/drivers/virtualization/ivshmem/doorbell \
-DCONFIG_CHECK_INIT_PRIORITIES=y
...
ERROR: /soc/pcie@4010000000 PRE_KERNEL_1 40 <
/soc/interrupt-controller@8000000/its@8080000 POST_KERNEL 40
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This allows finding the correct PCIe device when multiple devices
have the same vendor-id/device-id but differ in the class-rev register
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
For architectures that rely on a PCIe controller (for example, ARM64),
scanning the PCI space will only succeed after the controller has
initialized. Therefore, in the presence of PCIe controller, the PCIe
initialization is bumped to the next system init level.
In the past, drivers like ivshmem would do a late scan of the PCI space
in case the early scan failed; however, the cited commit removed this
feature and ivshmem fails for ARM64. This commit fix this by making the
early scan succeed.
Fixes: a96016d747 ("drivers: ivshmem: Remove unnecessary BDF lookup ...")
Signed-off-by: Rodrigo Cataldo <rodrigo.cataldo@huawei.com>
Co-authored-by: Henri Xavier <datacomos@huawei.com>
Take advantage of the new PCIe scanning API for doing the initial lookup
of PCIe devices specified for a given board.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This adds a generic API to be used for scanning for available PCI
endpoints. It takes a more detailed approach than the "brute force"
based scanning that's so far been used in Zephyr, buy inspecting the
host controller node and bridge nodes, and only scanning for busses and
devices that are actually expected to exist.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
PCI(e) host controllers behave in different ways (some more buggy than
others) in what value they use to indicate that an endpoint is not
present. In most cases the VID/DID is all ones (PCIE_ID_NONE) but in
others it's all zeroes, and some may even have the VID all zeroes and
the DID all ones, or vice-versa.
Add a macro to easily test for all these possibilities. The "all ones"
and "all zeroes" cases have been verified to exist on actual HW
supported by Zephyr, however the test for the mixed cases is simply
based on what Linux considers valid values (drivers/pci/probe.c in the
Linux kernel tree).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The BDF values can differ on the same platform, based on e.g. BIOS
configuration, and in the case of qemu the command line parameters. It's
therefore more reliable to always look up the BDF value based on the
known Vendor and Device IDs.
This patch introduces such a framework, and allows the incremental
update of PCIe drivers to start taking advantage of it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
MISRA C:2012 Rule 14.4 (The controlling expression of an if statement
and the controlling expression of an iteration-statement shall have
essentially Boolean type.)
Use `do { ... } while (false)' instead of `do { ... } while (0)'.
Use comparisons with zero instead of implicitly testing integers.
The commit is a subset of the original auditable-branch commit:
5d02614e34a86b549c7707d3d9f0984bc3a5f22a
Signed-off-by: Simon Hein <SHein@baumer.com>
Invert the physical address given to pcie_ctrl_region_translate() to
match the PCI BAR layout. Previously, physical addresses for memory
space BAR were exposed to bit 3 (prefetchable bit) and 2 (1 type bit) of
the header.
Signed-off-by: Rodrigo Cataldo <rodrigo.cataldo@huawei.com>
MISRA C:2012 Rule 7.2 (A `u' or `U' suffix shall be applied to all
integer constants that are represented in an unsigned type)
Added missing `U' suffixes in constants that are involved in the
analyzed build, plus a few more not to introduce inconsistencies
with respect to nearby constants that are either unused in the
build (but implicitly unsigned) or are used and are immediately
converted to unsigned.
Signed-off-by: Abramo Bagnara <abramo.bagnara@bugseng.com>
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>
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>
The is meant to fix a chicken & egg issue with MSI interrupt remapping.
Currently, drivers first connect the irq (by-passing any possible MSI
remapping), so the IRQ ends-up being remapped at the IOAPIC level which
is not what we want.
So adding a dedicated function to properly handle this case. This is
valid only for runtime dynamic IRQ connection obviously.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
PCIE now uses the new interface. And pcie_alloc_irq() is only made
available when CONFIG_PCIE_CONTROLLER is unset. So only for x86 atm.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.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>
Extend the PCIe API to find Extended Capabilities in the PCI Express
Extended Capabilities located in Configuration Space at offsets 256
or greater.
Note: the Root Complex Register Block is not supported
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
This changes pci_msi_enable() to take IRQ number as a function
parameter. The old behavior relies on putting the IRQ number
into the interrupt line register in the PCI config space
during IRQ allocation, and reading it back when enabling IRQ.
However, the interrupt line register is only required to be
read-/writable when legacy interrupt is supported on the device.
Otherwise it has undefined behavior. On ACRN, they don't even
care about this register and always wires it to 0x00.
So this commit changes the behavior in pci_msi_enable() to not
require reading back the interrupt line register and instead
takes the IRQ number via function parameter.
Fixes#36765
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
So far pcie_get_mbar() has been the only way to retrieve a MBAR. But
it's logic does not fit all uses cases as we will see further.
The meaning of its parameter "index" is not about BAR index but about
a valid Base Address count instead. It's an arbitrary way to index
MBARs unrelated to the actual BAR index.
While this has proven to be just the function we needed so far, this has
not been the case for MSI-X, which one (through BIR info) needs to
access the BAR by their actual index. Same as ivshmem in fact, though
that one did not generate any bug since it never has IO BARs nor 64bits
BARs (so far?).
So:
- renaming existing pcie_get_mbar() to pcie_probe_mbar(), which is a
more relevant name as it indeed probes the BARs to find the nth valid
one.
- Introducing a new pcie_get_mbar() which this time really asks for the
BAR index.
- Applying the change where relevant. So all use pcie_probe_mbar() now
but MSI-X and ivshmem.
Fixes#37444
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
In some cases we cannot know the BDF up-front, so provide a way to
look it up based on the vendor and device ID.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This enables software MSI "multi-vector" feature, letting the user to
register an isr handler per-MSI message.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Though it was noted that pcie_get_cap() is only used by MSI code so far,
there is no need to put it in msi code. If unused, linker will nuke it.
So let's move things to where it belongs to.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
An address might be made for 64bit though it's lower 32 bits are made of
0. Also Simplifying the overall by removing a useless variable.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
currently pcie_get_mbar only returns the physical address.
This changes the function to return the size of the mbar and
the flags (IO Bar vs MEM BAR).
Signed-off-by: Maximilian Bachmann <m.bachmann@acontis.com>
There are x86 platforms where the IRQ configuration register for PCIe
is not pre-populated and the OS needs to assign a number dynamically
by writing to the register.
In order to allocate interrupts we have to know which ones have been
hard-coded in device tree. We accomplish this by collecting these
values through the IRQ_CONNECT() macro and placing them in a dedicated
linker section (in ROM).
The full set of allocated interrupts are managed through a bitmap, and
the pre-allocated values (from the linker section) are inserted into
this upon initial runtime access.
This patch introduces a new pcie_alloc_irq() API that drivers can use
to allocate interrupt line numbers. The two in-tree drivers that were
using this API (I2C and UART) are converted to use the new API.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With this refactoring of pcie directory, RC drivers are placed under
host/ directory, EP drivers are placed under endpoint/ directory and
they are completely independent of each other.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
