From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2241FC28CC3 for ; Fri, 31 May 2019 07:50:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0128C25C1A for ; Fri, 31 May 2019 07:50:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726824AbfEaHuL (ORCPT ); Fri, 31 May 2019 03:50:11 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:43751 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725955AbfEaHuL (ORCPT ); Fri, 31 May 2019 03:50:11 -0400 Received: by mail-qt1-f196.google.com with SMTP id z24so10238728qtj.10; Fri, 31 May 2019 00:50:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GwaITjmEuTof6u7MeG3GyILN9L8qj0XaOeE2YibaLeg=; b=iPV7jVvzfu9YBzUX9T7bjvZwCOcxrN0Hd8HIWSZd5Uz2NGNBB5fhx0B2M35RsSUvBk 6kDrnKeZ1nBvYxjBZB2uZDW6P/fLPFtRlEkT3tmPWZXCCqo5IzZIZt6nQj9V/zCi7QDX WO675+pXDp8uArx7zCW2LivpTvq1Flg3Kqs/DgS/pCrSKMfqlp+3IVWMSRpdnKI1BX8D G4UCNOEHXna9mGYk8Mn+VsXqnRrjr180ps8a2VHXypqqZqxQY7kvcp1Gk72uGrafZTFs 3YotdQjKlqfm7yORpLJRKXEBne0LlO3KeF0NjdFcqGEYbXPRcd29PvNMWCWzYdYAijLy FEww== X-Gm-Message-State: APjAAAX14/AWRBYMgE5giXl5h22Q2myejED9QTJTTSIO0wYpQKQrxtnw dmGZ18UPkAi4/838w+qKTAx1hENxPR2UGCodlTQ= X-Google-Smtp-Source: APXvYqwQB/JhCGjqlpNaldYQoGI4yfCEZhY1gzjbw3cSbTwub4t7W4H0B3NZ9jqg8ZYIlsA2SYsCySbJzJJdaOlmM1Y= X-Received: by 2002:aed:2bc1:: with SMTP id e59mr6984448qtd.7.1559289010013; Fri, 31 May 2019 00:50:10 -0700 (PDT) MIME-Version: 1.0 References: <1558650258-15050-1-git-send-email-alan.mikhak@sifive.com> <305100E33629484CBB767107E4246BBB0A6FAFFD@DE02WEMBXB.internal.synopsys.com> <305100E33629484CBB767107E4246BBB0A6FC308@DE02WEMBXB.internal.synopsys.com> <192e3a19-8b69-dfaf-aa5c-45c7087548cc@ti.com> <20190531050727.GO15118@vkoul-mobl> <20190531063247.GP15118@vkoul-mobl> In-Reply-To: <20190531063247.GP15118@vkoul-mobl> From: Arnd Bergmann Date: Fri, 31 May 2019 09:49:53 +0200 Message-ID: Subject: Re: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework To: Vinod Koul Cc: Kishon Vijay Abraham I , Alan Mikhak , Gustavo Pimentel , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "gregkh@linuxfoundation.org" , "jingoohan1@gmail.com" , "bhelgaas@google.com" , "wen.yang99@zte.com.cn" , "kjlu@umn.edu" , "linux-riscv@lists.infradead.org" , "palmer@sifive.com" , "paul.walmsley@sifive.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 31, 2019 at 8:32 AM Vinod Koul wrote: > On 31-05-19, 10:50, Kishon Vijay Abraham I wrote: > > On 31/05/19 10:37 AM, Vinod Koul wrote: > > > On 30-05-19, 11:16, Kishon Vijay Abraham I wrote: > > >> > > >> right, my initial thought process was to use only dmaengine APIs in > > >> pci-epf-test so that the system DMA or DMA within the PCIe controller can be > > >> used transparently. But can we register DMA within the PCIe controller to the > > >> DMA subsystem? AFAIK only system DMA should register with the DMA subsystem. > > >> (ADMA in SDHCI doesn't use dmaengine). Vinod Koul can confirm. > > > > > > So would this DMA be dedicated for PCI and all PCI devices on the bus? > > > > Yes, this DMA will be used only by PCI ($patch is w.r.t PCIe device mode. So > > all endpoint functions both physical and virtual functions will use the DMA in > > the controller). > > > If so I do not see a reason why this cannot be using dmaengine. The use > > > > Thanks for clarifying. I was under the impression any DMA within a peripheral > > controller shouldn't use DMAengine. > > That is indeed a correct assumption. The dmaengine helps in cases where > we have a dma controller with multiple users, for a single user case it > might be overhead to setup dma driver and then use it thru framework. > > Someone needs to see the benefit and cost of using the framework and > decide. I think the main question is about how generalized we want this to be. There are lots of difference PCIe endpoint implementations, and in case of some licensable IP cores like the designware PCIe there are many variants, as each SoC will do the implementation in a slightly different way. If we can have a single endpoint driver than can either have an integrated DMA engine or use an external one, then abstracting that DMA engine helps make the driver work more readily either way. Similarly, there may be PCIe endpoint implementations that have a dedicated DMA engine in them that is not usable for anything else, but that is closely related to an IP core we already have a dmaengine driver for. In this case, we can avoid duplication. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A098C04AB6 for ; Fri, 31 May 2019 07:50:18 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6E8232610F for ; Fri, 31 May 2019 07:50:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eIZbV0cH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E8232610F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HG2oDPs++NXpAi5An5hR2f3mJvd/M/fb6NfF78mpaLI=; b=eIZbV0cH9O1IyL ZvSidMAfgkyrOXE+NUnIYyGJs2RiDs8ts+x9K13DAz0WBNuVmEbK8nfgZst0Xqz8isR2CFaRgDUWp YZAI58cm2vzyr/9yKrGl4nAYALAcmUvd3PODmquAyUgzvDP/nLx3Gja55stjjOHfnpqIvxTMxluYb sBkT+vHhZp5IMRSfKFz86x/I7kg4ivE6SGE/rok6Y/GIjZeWsx7BRc4+Vl6+pqZr9Rw0wyJ+kdSQt sPF5SYqCrEXhXTqs3laOIAjzGfhvf4HfFWeACikgV7XgdvCO1SlHgzYRQEDiIGoiGGKrA8OABdfGQ JIVg7kmm49bBfQ2xKANg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWcIo-0002Ue-Uw; Fri, 31 May 2019 07:50:14 +0000 Received: from mail-qt1-f194.google.com ([209.85.160.194]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWcIm-0002Ty-IU for linux-riscv@lists.infradead.org; Fri, 31 May 2019 07:50:13 +0000 Received: by mail-qt1-f194.google.com with SMTP id x47so6891975qtk.11 for ; Fri, 31 May 2019 00:50:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GwaITjmEuTof6u7MeG3GyILN9L8qj0XaOeE2YibaLeg=; b=HUivt0K24yj2qAzq3BkLn1nvlEMMZf9nenNsAaWbbVUhbecdaKOW+YU8CIgkvA5ihR VizUnJ6GAoOzVxJCFqeRy6rnMNS5+wZZn1w91Ud4DQmRMgbzn/mMqb/B7dVqo6+j9iEW 83sYf7T41qmLNVglFVZR4rRNaxTRA9dkM/PsvPPyJkm4fWq5MQyN+sSP3WlnaXHUjee9 VxDCpm2rI23aQ/I8D4igPXFmzFUf3XOUNHJeIXEXIN9Q/RX2BcBKGbOghOT3bnDr0aAo BD+SaW6HpEe040lJ8fRe6IPLwpK0cAVOqHan7iD0SmSPZ9IreO2dgA5ueDQ+8Qn+nLLj xfdw== X-Gm-Message-State: APjAAAVSXRPKAvHQ8MgLLX4E/v3jHPNqi1eTL0sVvAOyulegZBYAPCY2 8CloiaMLbIzdtH8UlIw/j8ZZw2j62o8+vSiCjIY= X-Google-Smtp-Source: APXvYqwQB/JhCGjqlpNaldYQoGI4yfCEZhY1gzjbw3cSbTwub4t7W4H0B3NZ9jqg8ZYIlsA2SYsCySbJzJJdaOlmM1Y= X-Received: by 2002:aed:2bc1:: with SMTP id e59mr6984448qtd.7.1559289010013; Fri, 31 May 2019 00:50:10 -0700 (PDT) MIME-Version: 1.0 References: <1558650258-15050-1-git-send-email-alan.mikhak@sifive.com> <305100E33629484CBB767107E4246BBB0A6FAFFD@DE02WEMBXB.internal.synopsys.com> <305100E33629484CBB767107E4246BBB0A6FC308@DE02WEMBXB.internal.synopsys.com> <192e3a19-8b69-dfaf-aa5c-45c7087548cc@ti.com> <20190531050727.GO15118@vkoul-mobl> <20190531063247.GP15118@vkoul-mobl> In-Reply-To: <20190531063247.GP15118@vkoul-mobl> From: Arnd Bergmann Date: Fri, 31 May 2019 09:49:53 +0200 Message-ID: Subject: Re: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework To: Vinod Koul X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190531_005012_614247_FE818A5D X-CRM114-Status: GOOD ( 20.07 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "lorenzo.pieralisi@arm.com" , "gregkh@linuxfoundation.org" , Gustavo Pimentel , "palmer@sifive.com" , "kjlu@umn.edu" , "linux-kernel@vger.kernel.org" , Kishon Vijay Abraham I , "bhelgaas@google.com" , Alan Mikhak , "paul.walmsley@sifive.com" , "linux-pci@vger.kernel.org" , "jingoohan1@gmail.com" , "linux-riscv@lists.infradead.org" , "wen.yang99@zte.com.cn" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org On Fri, May 31, 2019 at 8:32 AM Vinod Koul wrote: > On 31-05-19, 10:50, Kishon Vijay Abraham I wrote: > > On 31/05/19 10:37 AM, Vinod Koul wrote: > > > On 30-05-19, 11:16, Kishon Vijay Abraham I wrote: > > >> > > >> right, my initial thought process was to use only dmaengine APIs in > > >> pci-epf-test so that the system DMA or DMA within the PCIe controller can be > > >> used transparently. But can we register DMA within the PCIe controller to the > > >> DMA subsystem? AFAIK only system DMA should register with the DMA subsystem. > > >> (ADMA in SDHCI doesn't use dmaengine). Vinod Koul can confirm. > > > > > > So would this DMA be dedicated for PCI and all PCI devices on the bus? > > > > Yes, this DMA will be used only by PCI ($patch is w.r.t PCIe device mode. So > > all endpoint functions both physical and virtual functions will use the DMA in > > the controller). > > > If so I do not see a reason why this cannot be using dmaengine. The use > > > > Thanks for clarifying. I was under the impression any DMA within a peripheral > > controller shouldn't use DMAengine. > > That is indeed a correct assumption. The dmaengine helps in cases where > we have a dma controller with multiple users, for a single user case it > might be overhead to setup dma driver and then use it thru framework. > > Someone needs to see the benefit and cost of using the framework and > decide. I think the main question is about how generalized we want this to be. There are lots of difference PCIe endpoint implementations, and in case of some licensable IP cores like the designware PCIe there are many variants, as each SoC will do the implementation in a slightly different way. If we can have a single endpoint driver than can either have an integrated DMA engine or use an external one, then abstracting that DMA engine helps make the driver work more readily either way. Similarly, there may be PCIe endpoint implementations that have a dedicated DMA engine in them that is not usable for anything else, but that is closely related to an IP core we already have a dmaengine driver for. In this case, we can avoid duplication. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv