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;
Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates
 188.184.36.48 as permitted sender) receiver=protection.outlook.com;
 client-ip=188.184.36.48; helo=cernmxgwlb4.cern.ch;
From:   Federico Vaga <federico.vaga@cern.ch>
To:     Vinod Koul <vkoul@kernel.org>
Reply-To: <federico.vaga@cern.ch>
CC:     <linux-kernel@vger.kernel.org>, <dmaengine@vger.kernel.org>
Subject: Re: dmaengine: usage of dmaengine_get() and dma_find_channel()
Date:   Wed, 23 Jan 2019 13:36:40 +0100
Message-ID: <2574032.sm3A0MmqI8@pcbe13614>
In-Reply-To: <20190123121521.GM4635@vkoul-mobl>
References: <23108003.0nNWatJzJB@pcbe13614> <20190123121521.GM4635@vkoul-mobl>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2019 12:36:44.5193
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7baef89e-b54c-4190-e11c-08d6812f6f2c
X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19;Ip=[188.184.36.48];Helo=[cernmxgwlb4.cern.ch]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR06MB4012
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Thanks for your suggestion

On Wednesday, January 23, 2019 1:15:21 PM CET Vinod Koul wrote:
> 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)