Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1004000rwb; Fri, 7 Oct 2022 07:02:33 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7H5yjAOKwsaviQcbjhbN/YokVoh9N5aVYBs/ttBVavoO4Ifl+6Q577UkU4G80x8/jN5Czh X-Received: by 2002:a63:1215:0:b0:43a:827d:dd with SMTP id h21-20020a631215000000b0043a827d00ddmr4895023pgl.98.1665151352927; Fri, 07 Oct 2022 07:02:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665151352; cv=none; d=google.com; s=arc-20160816; b=A4TmamlI1tt316s50nTn8eih0DCMAqgVDXgLRLzQHmFqQP3eX45o9q9P09f8XiLBI8 inTliEUwCya8XzIsN10THkrnuJf+tO54GE8MatoQ5rrusQMIxOyq+5u34rgsw81HqtHV 1Zb7S8xf1dFRvRQoLdQmxUnOOjFXVBiG5X1EMlx/NTe5YJN6wW5yEMRZfEnm2L2U/uAe fpdLjxipKb4V0KPi+QLntMvuXzJGzpKzCq6EdhWnkyBLXEorPHlqt4pf6N4ZE67ZVYfs MtX1Poxmq7sQu0ywUpwfpzKVs6OWvAbgzLbLGUWGT3DZaLFQNAPofA1asHMnO0H+lT5F 7z4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=sawJrBA64qq1LvvpgP9ShBUMGiO4TXLDPYXoJ7ohc4w=; b=LKAXK8lDnKLuDZzD7ko7cuDpJcQ13r95r8+Obhm5mykcPcC/+tUXRd7zKVefryS80k X6jp0wNNdDYg8fBIbm7ehuSeQoxFZoiPICyIU+ygCte839Ynt/+KvS4XVsJjoRvBHcCz g8UDZo88+dCedia16+pqp2N6IzW3a1VdAH0jowK2MzNy88krVaXnSCx5CNeKR2GurG/D vkvk5nkZKgwbXmax4WPanLdeVBv4aWXDNcXZiHKJx1hUyHEZYF9JaH0l43EeUy5W/Jdu Zg227/nn71exUorvt2nqsJOjHFRGa552GpbQYQXBYJtfjAE5Fr1w40Fe20a+Um9D8tjq IuEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l1-20020a17090270c100b00178a33f8bb4si2138195plt.328.2022.10.07.07.01.56; Fri, 07 Oct 2022 07:02:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229867AbiJGNVV (ORCPT + 99 others); Fri, 7 Oct 2022 09:21:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229630AbiJGNVR (ORCPT ); Fri, 7 Oct 2022 09:21:17 -0400 Received: from mx.gpxsee.org (mx.gpxsee.org [37.205.14.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EA4F79E2ED; Fri, 7 Oct 2022 06:21:12 -0700 (PDT) Received: from [192.168.4.25] (unknown [62.77.71.229]) by mx.gpxsee.org (Postfix) with ESMTPSA id 1104D44632; Fri, 7 Oct 2022 15:21:10 +0200 (CEST) Message-ID: Date: Fri, 7 Oct 2022 15:21:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH V6 XDMA 0/2] xilinx XDMA driver Content-Language: en-US To: Lizhi Hou , vkoul@kernel.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, trix@redhat.com Cc: max.zhen@amd.com, sonal.santan@amd.com, larry.liu@amd.com, brian.xu@amd.com References: <1664919839-27149-1-git-send-email-lizhi.hou@amd.com> <4e4481e9-0eb9-ac28-b9ff-348adb4dc866@gpxsee.org> From: =?UTF-8?Q?Martin_T=c5=afma?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06. 10. 22 19:42, Lizhi Hou wrote: > > On 10/6/22 09:37, Martin Tůma wrote: >> On 04. 10. 22 23:43, Lizhi Hou wrote: >>> Hello, >>> >>> This V6 of patch series is to provide the platform driver to support the >>> Xilinx XDMA subsystem. The XDMA subsystem is used in conjunction with >>> the >>> PCI Express IP block to provide high performance data transfer >>> between host >>> memory and the card's DMA subsystem. It also provides up to 16 user >>> interrupt wires to user logic that generate interrupts to the host. >>> >>>              +-------+       +-------+       +-----------+ >>>     PCIe     |       |       |       |       |           | >>>     Tx/Rx    |       |       |       |  AXI  |           | >>>   <=======>  | PCIE  | <===> | XDMA  | <====>| User Logic| >>>              |       |       |       |       |           | >>>              +-------+       +-------+       +-----------+ >>> >>> The XDMA has been used for Xilinx Alveo PCIe devices. >>> And it is also integrated into Versal ACAP DMA and Bridge Subsystem. >>>      https://www.xilinx.com/products/boards-and-kits/alveo.html >>> https://docs.xilinx.com/r/en-US/pg344-pcie-dma-versal/Introduction-to-the-DMA-and-Bridge-Subsystems >>> >>> The device driver for any FPGA based PCIe device which leverages XDMA >>> can >>> call the standard dmaengine APIs to discover and use the XDMA subsystem >>> without duplicating the XDMA driver code in its own driver. >>> >>> Changes since v5: >>> - Modified user logic interrupt APIs to handle user logic IP which >>> does not >>>    have its own register to enable/disable interrupt. >>> - Clean up code based on review comments. >>> >>> Changes since v4: >>> - Modified user logic interrupt APIs. >>> >>> Changes since v3: >>> - Added one patch to support user logic interrupt. >>> >>> Changes since v2: >>> - Removed tasklet. >>> - Fixed regression bug introduced to V2. >>> - Test Robot warning. >>> >>> Changes since v1: >>> - Moved filling hardware descriptor to xdma_prep_device_sg(). >>> - Changed hardware descriptor enum to "struct xdma_hw_desc". >>> - Minor changes from code review comments. >>> >>> Lizhi Hou (2): >>>    dmaengine: xilinx: xdma: Add xilinx xdma driver >>>    dmaengine: xilinx: xdma: Add user logic interrupt support >>> >>>   MAINTAINERS                            |   11 + >>>   drivers/dma/Kconfig                    |   13 + >>>   drivers/dma/xilinx/Makefile            |    1 + >>>   drivers/dma/xilinx/xdma-regs.h         |  171 ++++ >>>   drivers/dma/xilinx/xdma.c              | 1034 ++++++++++++++++++++++++ >>>   include/linux/dma/amd_xdma.h           |   16 + >>>   include/linux/platform_data/amd_xdma.h |   34 + >>>   7 files changed, 1280 insertions(+) >>>   create mode 100644 drivers/dma/xilinx/xdma-regs.h >>>   create mode 100644 drivers/dma/xilinx/xdma.c >>>   create mode 100644 include/linux/dma/amd_xdma.h >>>   create mode 100644 include/linux/platform_data/amd_xdma.h >>> >> >> Hi, >> I have rewritten our V4L2 driver to use this new XDMA driver, but it >> does not work on our HW (where the previous Xilinx XDMA driver derived >> from the Xilinx sample code worked fine). The driver is sucessfully >> loaded and 4(2+2) DMA channels are successfully created. But when a >> DMA transfer is initiated, I get an error from my PC's DMA chip: >> >> AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0x36a00000 >> flags=0x0000] >> >> and no error from XDMA. >> >> Does the driver expect some special FPGA IP core configuration? Or is >> there something else I'm missing? My code is quiet similar to what you >> use in your XRT repo on GitHub (there is btw. a bug in the XRT code - >> you do not clear the dma_slave_config struct before using) but in my >> case the DMA transfer triggers the AMD-Vi error and timeouts. >> >> The code of our driver is attached, the relevant parts are in mgb4_dma.c >> and mgb4_core.c. >> >> M. > > Hi Martin, > > Thanks for trying this and got a lot thing works. I have read your > driver. Could you call pci_map_sg() before calling prep_sg()? (and > pci_unmap_sg()) after transfer complete? > > example: > https://github.com/houlz0507/XRT-1/blob/xdma_v4_usage/src/runtime_src/core/pcie/driver/linux/xocl/subdev/xdma.c#L103 > > > Thanks, > > Lizhi > Hi, That's not the problem, the sg is already mapped by V4L2 videobuf-dma-sg (https://elixir.bootlin.com/linux/v6.0/source/drivers/media/v4l2-core/videobuf-dma-sg.c#L285). With the original XDMA driver I was also not mapping the sg and it worked fine. And yes, I have tried it anyway and it didn't help ;-) So there must be some other problem in your XDMA driver. M.