[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXsUPAW5zKrsaTR9Tgv7kFdkz8s_QUjLXq6zDpoo47fRA@mail.gmail.com>
Date: Tue, 21 Feb 2023 14:25:59 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Lizhi Hou <lizhi.hou@....com>
Cc: vkoul@...nel.org, dmaengine@...r.kernel.org,
linux-kernel@...r.kernel.org, max.zhen@....com,
sonal.santan@....com, larry.liu@....com, brian.xu@....com,
tumic@...see.org
Subject: Re: [RESEND PATCH V12 XDMA 1/2] dmaengine: xilinx: xdma: Add xilinx
xdma driver
Hi Lizhi,
On Thu, Feb 9, 2023 at 8:18 PM Lizhi Hou <lizhi.hou@....com> 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@....com>
> Signed-off-by: Sonal Santan <sonal.santan@....com>
> Signed-off-by: Max Zhen <max.zhen@....com>
> Signed-off-by: Brian Xu <brian.xu@....com>
> Tested-by: Martin Tuma <tumic@...see.org>
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?
> +static const struct platform_device_id xdma_id_table[] = {
> + { "xdma", 0},
> + { },
> +};
This table is not needed, as the single entry matches driver.name below.
> +
> +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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists