Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp704905imu; Wed, 23 Jan 2019 04:19:08 -0800 (PST) X-Google-Smtp-Source: ALg8bN41a0XdLPLx6k+GZQvvXxjBXUuAUfRGoXf4mmXhKUC+h3cZnsBtR5rIUS7eOBH9FhTV1mO0 X-Received: by 2002:a62:4c:: with SMTP id 73mr1823159pfa.24.1548245947976; Wed, 23 Jan 2019 04:19:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548245947; cv=none; d=google.com; s=arc-20160816; b=kGUKvTO7BUOszukspY85USkJQF4cqj/sj81/xhyWf9HHTByPEAkmKDL7eL+EWdh8e2 4hHfyjQsLkphhEqBrAsTKFzDt4c9Yb9y1+tUOYnxGT4eOkRdAOO5ad4V5DX9R0GIiKcb PzFLPAXENsO/2RS8GZRKFc2TF49CcbhWFF9CzC4UVIUfJXXQ8SbEjTcsKjp0nGa6gTqd HAmfb3EQIULfOpS94x0DcmZrSQaQXtsNyvI2dAS1EWDjmNqhEjkQ0uBBwVE3pvheSHYu 0lLE9vDIuaWoaMZ9QmtjZYwaWWzPV3RJXKw7KZsG3TvWfLO5Z2Bu1WJCIWihdZRSLDw0 ls4w== 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=HX9qGBKnrXqf2+zY3JXmh8y83atxtPQ7F9THCuAYJtE=; b=alnnj91GOzGz/vqXtFqlELE5mK/07R+FzNO4HxCGShOvo4MeCQbYbAh/sTn5HnclSV 8OScOdHd83Gu4WgkcmQzQsiZlLO3lKViTX+pHc0uiIfabh6MdZoKPj3sspkuAfKkwwhY 86LIanbFc7UzaRY+mMJ5K0MyaX2ps3ehF9bH7yuXwXVjQUPGhBRwtG4WuMnwslh/QqrB Kxd23udUFQ1ABf02jZZB10IHeXmlBHQf4A4ZT7XKXe2Xrh8xa4iLActOrhLOiKVl8/9k XRi9YXTsEArM/M4gceTWGsSiOnmGCIZym8Vc13PErWjtwZ1pHxGy62Wn+8+KTBmVHoCf tIZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=2Poht8yJ; 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 r34si19108218pga.242.2019.01.23.04.18.51; Wed, 23 Jan 2019 04:19:07 -0800 (PST) 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=2Poht8yJ; 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 S1727075AbfAWMQy (ORCPT + 99 others); Wed, 23 Jan 2019 07:16:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:47276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726029AbfAWMQy (ORCPT ); Wed, 23 Jan 2019 07:16:54 -0500 Received: from localhost (unknown [106.200.229.238]) (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 836EF20861; Wed, 23 Jan 2019 12:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548245813; bh=sYpBi9Rv15CsOdOlrt6+JUPIBr033oHvZ52AthQyOao=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=2Poht8yJz86OvJzoNsvR1ib6WGFUEeuthADX0MQ4Xyk7h041YQBhQzAIAN6Prl9Bf JmFWoquZ8+W2dgtI94BaDisrZVeMuOHevBBO6jE5pM8BctJWaE8sjmF/QpEcyzRDv0 qArttKYzKIJXJdZusuTBNt5SpTjPkYPNDat3a4RQ= Date: Wed, 23 Jan 2019 17:45:21 +0530 From: Vinod Koul To: Federico Vaga Cc: linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org Subject: Re: dmaengine: usage of dmaengine_get() and dma_find_channel() Message-ID: <20190123121521.GM4635@vkoul-mobl> References: <23108003.0nNWatJzJB@pcbe13614> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23108003.0nNWatJzJB@pcbe13614> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21-01-19, 17:41, Federico Vaga wrote: > Hello, > > I am a bit puzzle about the proper usage these two functions: > > void dmaengine_get(void) > struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type) > > Looking into the kernel sources dma_find_channel is not used, despite the fact > that it looks as one of the suggested mechanism to access a DMA engine. So, I > cannot find a valid example of its usage. > > The same for dmaengine_get(). On the other hand, at least this function is > used in: drivers/video/fbdev/mx3fb.c. But I believe that its usage is wrong > because it uses: dmaengine_get() + dma_request_channel(), instead of > dmaengine_get() + dma_find_channel(). > > Reading the code my understanding is that dmaengine_get() + dma_find_channel() > should be used for "public" (not private) DMA engine channels. > > It's here where things are getting obscure to me. My understanding is that DMA > channels which are not private can be used by several drivers at the same > time. In principle they submit all their transfers and the DMA engine will > process them and then the DMA engine will notify the drivers about their > completion. The concept of public channel is a channel capable of doing any dma transfer for example a system dmaengine capable of flipping bits from system memory to memory/devices. For peripherals, we cannot do a generic transfer and the transfer is specific given a set of parameters for it to work, thus the channel is private... These channels can be used by many users as long as that is supported by engine. In an idle world, the dmaengine should have N channels and provide M software channels and lets users use them and schedule these for best throughput, we are not there yet :( > My understanding is also that the dmaengine subsystem assumes that "public" > channels of the same type are interchangeable. > > In my use case I wrote a DMA engine which is specific for a subset of driver, > and it cannot be used by others (so is sharable among a group of drivers). All > these drivers, potentially, they can submit their transfers to the DMA engine > in parallel; but I cannot do it because I'm forced to use > dma_request_channel() in order to be able to filter the DMA channels, and this > will make automatically the channel PRIVATE which prevents other drivers to > use the same channel. Please use virtual channels for that, clients can use virtual channels and they can be submitted to a hardware channel. > With the current API I do not see alternative for me. I have to use > dma_request_channel() in order to filter DMA channels. But I am wondering if > it make sense for you, and if it does, is there a solution today? Or, is it > possibile to design one? > > Thanks (I do not know if this message is clear enough) > -- ~Vinod