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>
Any exposed PTM root device will by default see their root capability
enabled so they will become PTM responder.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Such module is missing and will prove to be useful for future features
and/or printing out debug messages on existing ones.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Add __printf_like modifier to validate strings used by shell.
Fixing warnings triggered by this change.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Remove the locally MSI/MSI-X capabilities ID define and use the
newly introduced one from the PCI Code and ID Assignment
Specification Revision 1.11 document header.
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>
Instead of putting the object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
When enabling MSI & MSI-X, the code seemed to handle fallback to MSI
when MSI-X is not available, but the logic uses MSI-X even if not
available and the MSI path never gets used.
Fixes: a2491b321e ("drivers/pcie: Add support for MSI-X")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
When building on non-X86 platforms K_MEM_PERM_RW gets undefined.
Fixes: a2491b321e ("drivers/pcie: Add support for MSI-X")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.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>
These have been redefined in various places - better to have them in a
single place that different users can use.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Now that we generate a header that extern's all possible devicetree
based device struct we can remove DEVICE_DT_DECLARE and
DEVICE_DT_INST_DECLARE as they aren't needed anymore.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Renamed to make its semantics clearer; this function maps
*physical* memory addresses and is not equivalent to
posix mmap(), which might confuse people.
mem_map test case remains the same name as other memory
mapping scenarios will be added in the fullness of time.
Parameter names to z_phys_map adjusted slightly to be more
consistent with names used in other memory mapping functions.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
It's disabled by default. When enabled, and if the device exposes both
MSI and MSI-X capabilities: MSI-X will be selected and MSI disabled on
the device.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.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>
Originally, sys_read8 to the mapped address was added part of
the unmap API to protect OMAP mapping, i.e. in case of PCIe writes,
OMAP should not be overwritten before writes are completed.
Now that we have added dummy PCIe read in the common APIs, namely
pcie_ep_xfer_data_memcpy and pcie_ep_xfer_data_dma, for the purpose
of flushing PCIe writes; the purpose of protecting OMAP *also*
gets satisfied, randering PCIe read in the unmap useless,
so remove the same.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
Introduce common API to achieve data transfer using system DMA.
"System DMA" uses the outbound memory mapped Host address,
it cannot understand Host/PCIe address.
This API will take of mapping the Host address, completing
the data transfer to/from Host memory and unmapping the window;
thus providing abstraction to the user.
Since v1:
- refactored code for the cases where we have valid mapped_addr
to improve error management logic
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
Once host memory is mapped to outbound memory, PL330 can be used to
transfer data between outbound memory and local memory.
Add API for the same, we get pl330 device as well as channels to be
used for tx/rx from DT and use DMA public APIs for data transfer.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.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>
We should clear the pvm interrupts (snoop and pcie pmon lite interrupt)
at source before handling them.
This will make sure that we do not lose any interrupts that may have
been asserted to interrupt controller during the handling routine.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
Add support for interrupt driven MSI-X PVM feature for Viper.
Function mask bit update is tracked with snoop interrupt
and vector mask bit update is tracked with pcie pmon lite
address range access detection interrupt.
Both the interrupts are required to enable this feature.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
drivers: pcie_ep: iproc: move msi/msix functions to a separate
file. This increases readability and modularity.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
File names such as pcie_ep_bcm_iproc.c / pcie_ep_bcm_iproc_regs.h
seem unnecessarily long, same with CONFIG symbols' names.
Let's shorten them by replacing 'bcm_iproc' with simply 'iproc'.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.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>
The PCI API was originally limited to 32 bit addresses. Even though
it had code to skip over the high word in 64 bit BAR entries, it
refused to use it and returned a 32 bit value. Some devices in the
wild have default mappings from the firmware for devices above 4G.
Also remove the "iobar" API. It's dead code, we don't call it and we
don't test it. IO space BAR entries are a legacy feature from way,
way back in PCI history (I genuinely have never heard of a real device
that uses them!). And there's no difference in format between one of
these and a 32 bit "memory" BAR anyway, someone who actually had this
requirement could just use the existing API without worry.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
PCIe shell was enabled by default if shell is enabled in below commit:
commit ee985d81aa ("shell: enable modules by default if shell is
enabled").
However, this shell file has tests for PCIe RC, not applicable to EP.
So, should not be default enabled for PCIe EP.
If we add EP shell tests in future, they should be added under
drivers/pcie/endpoint/ directory.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
pcie has an all in one command for listing pci devices. Make it support
additional commands and move lspcie to `pcie ls`.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
If shell is enabled then enable all sub-shells if their dependencies are
satisfied. This was done for some modules and subsystems but was not
consistent.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
