On 2/21/23 05:25, Geert Uytterhoeven wrote:
Hi Lizhi,
On Thu, Feb 9, 2023 at 8:18 PM Lizhi Hou <lizhi.hou@xxxxxxx> wrote:
Add driver to enable PCIe board which uses XDMA (the DMA/Bridge Subsystem
for PCI Express). For example, Xilinx Alveo PCIe devices.
https://www.xilinx.com/products/boards-and-kits/alveo.html
The XDMA engine support up to 4 Host to Card (H2C) and 4 Card to Host (C2H)
channels. Memory transfers are specified on a per-channel basis in
descriptor linked lists, which the DMA fetches from host memory and
processes. Events such as descriptor completion and errors are signaled
using interrupts. The hardware detail is provided by
https://docs.xilinx.com/r/en-US/pg195-pcie-dma/Introduction
This driver implements dmaengine APIs.
- probe the available DMA channels
- use dma_slave_map for channel lookup
- use virtual channel to manage dmaengine tx descriptors
- implement device_prep_slave_sg callback to handle host scatter gather
list
- implement device_config to config device address for DMA transfer
Signed-off-by: Lizhi Hou <lizhi.hou@xxxxxxx>
Signed-off-by: Sonal Santan <sonal.santan@xxxxxxx>
Signed-off-by: Max Zhen <max.zhen@xxxxxxx>
Signed-off-by: Brian Xu <brian.xu@xxxxxxx>
Tested-by: Martin Tuma <tumic@xxxxxxxxxx>
Thanks for your patch, which is now commit 17ce252266c7f016
("dmaengine: xilinx: xdma: Add xilinx xdma driver") in dmaengine/next.
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -735,6 +735,20 @@ config XILINX_DMA
the scatter gather interface with multiple channels independent
configuration support.
+config XILINX_XDMA
+ tristate "Xilinx DMA/Bridge Subsystem DMA Engine"
+ depends on HAS_IOMEM
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ select REGMAP_MMIO
No platform dependencies at all, while this is a platform driver that
relies on some other not-yet-existing driver creating an "xdma"
platform device?
+ help
+ Enable support for Xilinx DMA/Bridge Subsystem DMA engine. The DMA
+ provides high performance block data movement between Host memory
+ and the DMA subsystem. These direct memory transfers can be both in
+ the Host to Card (H2C) and Card to Host (C2H) transfers.
+ The core also provides up to 16 user interrupt wires that generate
+ interrupts to the host.
+
config XILINX_ZYNQMP_DMA
tristate "Xilinx ZynqMP DMA Engine"
depends on ARCH_ZYNQ || MICROBLAZE || ARM64 || COMPILE_TEST
--- /dev/null
+++ b/drivers/dma/xilinx/xdma.c
+/**
+ * xdma_probe - Driver probe function
+ * @pdev: Pointer to the platform_device structure
+ */
+static int xdma_probe(struct platform_device *pdev)
+{
+ struct xdma_platdata *pdata = dev_get_platdata(&pdev->dev);
Platform data? No DT?
Do we still accept plain platform drivers?
The XDMA driver needs to support both the non-DT and DT use cases.
For the non-DT case the parent PCIe device driver will create the xdma
platform device and pass the required information to the xdma driver. An
example is
https://lore.kernel.org/dmaengine/5fbe6029-61d5-bba4-556b-2282153f21dc@xxxxxxxxxx/
For the DT use case, the xdma device will be populated by the FDT. This
part is WIP and will be enabled with future patches.
+static const struct platform_device_id xdma_id_table[] = {
+ { "xdma", 0},
+ { },
+};
This table is not needed, as the single entry matches driver.name below.
Thanks. I will create a patch to fix this.
Lizhi
+
+static struct platform_driver xdma_driver = {
+ .driver = {
+ .name = "xdma",
+ },
+ .id_table = xdma_id_table,
+ .probe = xdma_probe,
+ .remove = xdma_remove,
+};
+
+module_platform_driver(xdma_driver);
Gr{oetje,eeting}s,
Geert
