Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp133145ybi; Thu, 30 May 2019 22:08:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqwDVDglK3Od04F9K5bDmq0rRdasUoh5Bo8ZBce9IgZz0rwbWGs4SrkQB8waiQGDIK/zxaKP X-Received: by 2002:a63:d504:: with SMTP id c4mr6955150pgg.20.1559279338777; Thu, 30 May 2019 22:08:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559279338; cv=none; d=google.com; s=arc-20160816; b=iDM5shQwNL6SDC5j+tneaUWSI/bWUJMxags3y99+81KXUWcqN5zntoFqz1QU+wOj+c M7WD1mGYyXDfwaa8yJ3K5gI5BF9Ig2jL60Hbuw3SRfMaWJFLXlL7Dma0s1ldIwGgJKr1 Z2cwr2xquMathUkDEBKxYTHqLJqU+fM1YXOD9eytr3ZNKtw1ppltTcZt3rPFBguPEruy pbKkhACBDXJ8uWXJpkqHGEB6dFHwVizqFMNUHPB1JOPx3JYvHWQA3JMrqstL2hzIszQ3 Y635AoCIuThSnAIWqDqjGh2tVyx2XK2ponfMq4qv78vh3lbCDWxUit/iGk9N+1ooTq0Y aRJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=qcuqfhMuR4TtnjQEBD4QRMlGub8IBCyUhj1EGdcHBC0=; b=qnoMknfHW8kxGDkpN8cTddyI19eOBVtObsazdinsSbHS9DDW2UsrxMMZuzsqMX3DjN UsRsfVxCj72tCHAkZcY+A29HZ8Zgaso0Czfri5v1HB5pdxUfR5W6LzUhLq3+dNuoDtE6 bkInifMu9+IV8YH0qpeiz3zJruEMr1msfF/61yRNPKakxXIyL6/aKIRzOq9PX4nAVslT lWgoo79yyRePX5Ws1TChl+PmmRXGRaGgnBnORsK1xKbfOo3+NqdoOZqkgySfulVzm09G wendPyFX4Q0eliqIctnc7alOnGDnjabWtPVlP8I8EPY/CuI8Wpc0G3uiRaFJh2XoxjDT gFlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AquQ2Bgf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s12si4710075pji.93.2019.05.30.22.08.41; Thu, 30 May 2019 22:08:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AquQ2Bgf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726413AbfEaFHc (ORCPT + 99 others); Fri, 31 May 2019 01:07:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:34374 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725955AbfEaFHc (ORCPT ); Fri, 31 May 2019 01:07:32 -0400 Received: from localhost (unknown [106.201.101.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 83030247AF; Fri, 31 May 2019 05:07:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559279251; bh=BuY1+L8PZfblsP3QxroLV+WEJj4MRFA04xBR95ykdxA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AquQ2Bgfoikgd5TO4sJHzyaj/LT1Z9vqakg/1fT2DY332WLCRR9HUtHKZsTxQ+OgN ayAk//NFjxLiVcoqGaFtfzjoyKDh6d56R+XRh3HQ4da2svDXiCummIZ4OwZXRJfbyV 5asyWPhoCi7dva+x1pyXJLLlxYHDleiJBrKJVWEM= Date: Fri, 31 May 2019 10:37:27 +0530 From: Vinod Koul To: Kishon Vijay Abraham I Cc: Alan Mikhak , Gustavo Pimentel , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "arnd@arndb.de" , "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" Subject: Re: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework Message-ID: <20190531050727.GO15118@vkoul-mobl> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <192e3a19-8b69-dfaf-aa5c-45c7087548cc@ti.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kishon, On 30-05-19, 11:16, Kishon Vijay Abraham I wrote: > +Vinod Koul > > Hi, > > On 30/05/19 4:07 AM, Alan Mikhak wrote: > > On Mon, May 27, 2019 at 2:09 AM Gustavo Pimentel > > wrote: > >> > >> On Fri, May 24, 2019 at 20:42:43, Alan Mikhak > >> wrote: > >> > >> Hi Alan, > >> > >>> On Fri, May 24, 2019 at 1:59 AM Gustavo Pimentel > >>> wrote: > >>>> > >>>> Hi Alan, > >>>> > >>>> This patch implementation is very HW implementation dependent and > >>>> requires the DMA to exposed through PCIe BARs, which aren't always the > >>>> case. Besides, you are defining some control bits on > >>>> include/linux/pci-epc.h that may not have any meaning to other types of > >>>> DMA. > >>>> > >>>> I don't think this was what Kishon had in mind when he developed the > >>>> pcitest, but let see what Kishon was to say about it. > >>>> > >>>> I've developed a DMA driver for DWC PCI using Linux Kernel DMAengine API > >>>> and which I submitted some days ago. > >>>> By having a DMA driver which implemented using DMAengine API, means the > >>>> pcitest can use the DMAengine client API, which will be completely > >>>> generic to any other DMA implementation. > > 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? If so I do not see a reason why this cannot be using dmaengine. The use case would be memcpy for DMA right or mem to device (vice versa) transfers? Btw many driver in sdhci do use dmaengine APIs and yes we are missing support in framework than individual drivers > If DMA within the PCIe controller cannot be registered in DMA subsystem, we > should use something like what Alan has done in this patch with dma_read ops. > The dma_read ops implementation in the EP controller can either use dmaengine > APIs or use the DMA within the PCIe controller. > > I'll review the patch separately. > > Thanks > Kishon -- ~Vinod