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>
Add defines for all the PCI and PCIe capabilities from the PCI Code
and ID Assignment Specification Revision 1.11 document.
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>
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>
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>
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>
For a given PCIe EP device, data transfer to/from Host memory can be
achieved with "System DMA" between mapped Host memory
(PCIe outbound memory) and EP device's local memory if EP is equipped
with a "System DMA controller".
Add public API to enable such DMA transfers.
The term "System DMA" is used to clarify that we are not talking about
dedicated "PCIe DMA"; rather the one which does not understand PCIe
address directly, and uses the mapped Host memory.
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>
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>
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 End Point can get three different reset interrupts from the
Root Complex, Function Level Reset (FLR), PCI Express Reset (PERST)
and Inband PCI Express Reset (INB PERST).
Add public API to let PCIe EP drivers register callback function
for each PCIe reset interrupt. This callback function should be
executed from corresponding reset interrupt handler if registered.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
Introduce common API to achieve data transfer using memcpy
to/from outbound region of PCIe EP.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
Add public APIs for PCIe endpoint driver:
- EP configuration space read/write
- Mapping/Unmapping of Host buffer and PCIe outbound region
- Raise interrupt to Host
These are minimal base APIs to make PCIe EP functional.
Also, add a Kconfig and an empty CMakeLists.txt for drivers to extend.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
This trivial patch extends the PCIe shell to check for and report
on a device's ability to use MSI-X interrupt signaling.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Some firmwares (looking at you, slimbootloader) don't set the registers
in PCI configuration space to indicate the IRQ routing, so we remove
the check that verifies that the user and firmware agree on IRQ number.
Also eliminate the return value of pcie_irq_enable() since no one uses
it and we can't return a meaningful value any longer.
Signed-off-by: Charles Youse <charles.youse@intel.com>
Firmware is supposed to set a register in PCI configuration space which
indicates the hardware IRQ that the endpoint is attached to.
A function is implemented which reads this register, and the PCIe shell
is updated to use it instead of doing it "manually".
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
A new function pcie_irq_enable() is added to be used in lieu of
irq_enable() when the target device is PCI(e)-attached. The function
attempts to use MSI, when configured in the kernel and supported by
the endpoint; failing that, it will verify that IRQ requested is in
fact routed to the device by the boot firmware before enabling it.
The NS16550 UART driver is updated to use pcie_irq_enable().
The PCI(e) shell is extended to dump information about wired IRQs.
The up_squared devicetree is fixed (reverted?) to IRQ5 for UART1.
The galileo enables MSI by default.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
A parallel PCI implementation ("pcie") is added with features for PCIe.
In particular, message-signaled interrupts (MSI) are supported, which
are essential to the use of any non-trivial PCIe device.
The NS16550 UART driver is modified to use pcie.
pcie is a complete replacement for the old PCI support ("pci"). It is
smaller, by an order of magnitude, and cleaner. Both pci and pcie can
(and do) coexist in the same builds, but the intent is to rework any
existing drivers that depend on pci and ultimately remove pci entirely.
This patch is large, but things in mirror are smaller than they appear.
Most of the modified files are configuration-related, and are changed
only slightly to accommodate the modified UART driver.
Deficiencies:
64-bit support is minimal. The code works fine with 64-bit capable
devices, but will not cooperate with MMIO regions (or MSI targets) that
have high bits set. This is not needed on any current boards, and is
unlikely to be needed in the future. Only superficial changes would
be required if we change our minds.
The method specifying PCI endpoints in devicetree is somewhat kludgey.
The "right" way would be to hang PCI devices off a topological tree;
while this would be more aesthetically pleasing, I don't think it's
worth the effort, given our non-standard use of devicetree.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
