Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3900225ybl; Tue, 20 Aug 2019 04:07:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwZXi0uGGOLPdAgCCLO5t322MJ32Gk+EMXJUKKOdhRAehpfw6is4KQKBSBECMEsA4SOVcbP X-Received: by 2002:a65:68d9:: with SMTP id k25mr24346411pgt.337.1566299250302; Tue, 20 Aug 2019 04:07:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566299250; cv=none; d=google.com; s=arc-20160816; b=HjW+iTVBA1tA1+K2ngvkwwo1aMrqih5lNYqNbc1Dbcp/F1MMrkqib6ttL/UOmBlQ5J BM0uO1UNTTYV32C0pFdgFmGJ+04hxV7itIMPxSAsbThmTlaxcxKH1PdQ/p48iCFSkKNZ qurWbNdp7VnegDGHoEC0mgxbgWshB6sECb0tWEu9pl+efk22IXj53xMdhqxuAZ7oqp5V BIGc2VabDrIt6GPZWCjwTW0Y6YEmh6Emityy7bva6bLk8OnfL9sMp43bJUCqH/reHtil N5yHfvpxXsOGhA2McOYkG08LlZr2ZjfPu4EZm9d7Dg6egITFrjX7stseVUe6+srxBko2 +BuQ== 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=IqpR4flaOaWmzCPNPHOf8hvZMYxxclKxm9TbJXDmak8=; b=zkegWdYTlgGEIdZcKJIFPTnxzX1vojMqImjeTdiAXDsZQ2RBGr3I6cGW5caaHZF78I QXBVX5/dQAzGHD2OCKTceNd0MdlzMOYFhpAwur4UAYZw5msHurwoWmpC198O/WxOniZ4 /1L+wpgLn+i+yGoKIvBs/rPSuBpA3+4+Z9O/mZm7gHljx/OlIMj7Vzoa2/8x5Ql4DZhq UtthjRWOv4OUHOT27nKnQRNg0e6MxnfvHdDXtJrFXvnRMP6aaPGQGNA8v5tI2OHlZ5Na JCKtL5CMbQaNfM4cGXvqrrSr8bfS7pEY/X2QlVegHZJsLIJ7hT4seDH+pSuNghW6pKhI rfzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vn4zeb13; 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 g136si560056pfb.60.2019.08.20.04.07.15; Tue, 20 Aug 2019 04:07:30 -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=vn4zeb13; 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 S1729553AbfHTLGX (ORCPT + 99 others); Tue, 20 Aug 2019 07:06:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:58944 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728283AbfHTLGX (ORCPT ); Tue, 20 Aug 2019 07:06:23 -0400 Received: from localhost (unknown [106.201.62.126]) (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 C7D8720C01; Tue, 20 Aug 2019 11:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566299182; bh=zBcLo7GWdvo53ZL+qOqtR0PxkMh9A+yzuLf6IeQfgWE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vn4zeb13X6Id2TNzE5NpHZ9mBPZidwghpE4QL05SPMEilxDSOTDFS11uc6/MPCPVE yD/7atDqfthj1WUL8LciYesQcWmMUa2v2FOFCuUQlx8cDx/e9juk7JtVeHJnG2HNex +MdSEX1SM6t2ZYi/dECR2k9r0tU4E5OzprD5tqFE= Date: Tue, 20 Aug 2019 16:35:10 +0530 From: Vinod Koul To: Jon Hunter Cc: Sameer Pujar , Peter Ujfalusi , dan.j.williams@intel.com, tiwai@suse.com, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, sharadg@nvidia.com, rlokhande@nvidia.com, dramesh@nvidia.com, mkumard@nvidia.com Subject: Re: [PATCH] [RFC] dmaengine: add fifo_size member Message-ID: <20190820110510.GQ12733@vkoul-mobl.Dlink> References: <75be49ac-8461-0798-b673-431ec527d74f@nvidia.com> <20190719050459.GM12733@vkoul-mobl.Dlink> <3e7f795d-56fb-6a71-b844-2fc2b85e099e@nvidia.com> <20190729061010.GC12733@vkoul-mobl.Dlink> <98954eb3-21f1-6008-f8e1-f9f9b82f87fb@nvidia.com> <20190731151610.GT12733@vkoul-mobl.Dlink> <20190808123833.GX12733@vkoul-mobl.Dlink> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On 19-08-19, 16:56, Jon Hunter wrote: > >>>>>>> On this, I am inclined to think that dma driver should not be involved. > >>>>>>> The ADMAIF needs this configuration and we should take the path of > >>>>>>> dma_router for this piece and add features like this to it > >>>>>> > >>>>>> Hi Vinod, > >>>>>> > >>>>>> The configuration is needed by both ADMA and ADMAIF. The size is > >>>>>> configurable > >>>>>> on ADMAIF side. ADMA needs to know this info and program accordingly. > >>>>> > >>>>> Well I would say client decides the settings for both DMA, DMAIF and > >>>>> sets the peripheral accordingly as well, so client communicates the two > >>>>> sets of info to two set of drivers > >>>> > >>>> That maybe, but I still don't see how the information is passed from the > >>>> client in the first place. The current problem is that there is no means > >>>> to pass both a max-burst size and fifo-size to the DMA driver from the > >>>> client. > >>> > >>> So one thing not clear to me is why ADMA needs fifo-size, I thought it > >>> was to program ADMAIF and if we have client programme the max-burst > >>> size to ADMA and fifo-size to ADMAIF we wont need that. Can you please > >>> confirm if my assumption is valid? > >> > >> Let me see if I can clarify ... > >> > >> 1. The FIFO we are discussing here resides in the ADMAIF module which is > >> a separate hardware block the ADMA (although the naming make this > >> unclear). > >> > >> 2. The size of FIFO in the ADMAIF is configurable and it this is > >> configured via the ADMAIF registers. This allows different channels > >> to use different FIFO sizes. Think of this as a shared memory that is > >> divided into n FIFOs shared between all channels. > >> > >> 3. The ADMA, not the ADMAIF, manages the flow to the FIFO and this is > >> because the ADMAIF only tells the ADMA when a word has been > >> read/written (depending on direction), the ADMAIF does not indicate > >> if the FIFO is full, empty, etc. Hence, the ADMA needs to know the > >> total FIFO size. > >> > >> So the ADMA needs to know the FIFO size so that it does not overrun the > >> FIFO and we can also set a burst size (less than the total FIFO size) > >> indicating how many words to transfer at a time. Hence, the two parameters. > > > > Thanks, I confirm this is my understanding as well. > > > > To compare to regular case for example SPI on DMA, SPI driver will > > calculate fifo size & burst to be used and program dma (burst size) and > > its own fifos accordingly > > > > So, in your case why should the peripheral driver not calculate the fifo > > size for both ADMA and ADMAIF and (if required it's own FIFO) and > > program the two (ADMA and ADMAIF). > > > > What is the limiting factor in this flow is not clear to me. > > The FIFO size that is configured by the ADMAIF driver needs to be given > to the ADMA driver so that it can program its registers accordingly. The > difference here is that both the ADMA and ADMAIF need the FIFO size. Can you please help describing what it is programming using the FIFO size of ADMAIF? Thanks -- ~Vinod