From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753571AbbELTOV (ORCPT ); Tue, 12 May 2015 15:14:21 -0400 Received: from smtp03.smtpout.orange.fr ([80.12.242.125]:33063 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753412AbbELTOR (ORCPT ); Tue, 12 May 2015 15:14:17 -0400 X-ME-Helo: belgarion X-ME-Date: Tue, 12 May 2015 21:14:16 +0200 X-ME-IP: 92.156.128.44 From: Robert Jarzmik To: Vinod Koul Cc: Jonathan Corbet , Daniel Mack , Haojian Zhuang , dmaengine@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Arnd Bergmann Subject: Re: [PATCH v2 1/5] Documentation: dmaengine: pxa-dma design References: <1428781236-25806-1-git-send-email-robert.jarzmik@free.fr> <1428781236-25806-2-git-send-email-robert.jarzmik@free.fr> <20150508043616.GY3521@localhost> <87y4kzten5.fsf@belgarion.home> <20150512101201.GB5418@localhost> X-URL: http://belgarath.falguerolles.org/ Date: Tue, 12 May 2015 21:13:20 +0200 In-Reply-To: <20150512101201.GB5418@localhost> (Vinod Koul's message of "Tue, 12 May 2015 15:42:01 +0530") Message-ID: <87h9rhmwxb.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vinod Koul writes: > On Fri, May 08, 2015 at 02:52:46PM +0200, Robert Jarzmik wrote: >> Vinod Koul writes: >> >> Euh no, I meant that a transfer which is submitted and issued on a _phy_ >> doesn't wait for a _phy_ to stop and restart, but is submitted on a "running >> channel". The other drivers, especially mmp_pdma waited for the phy to stop >> before relaunching a new transfer. >> >> I don't have a clear idea on a better wording yet ... > Ah okay, with that explanation it helps, can you add that to > comments/documentation Sure, for v3. >> >> + This implies that the queuing doesn't wait for the previous transfer end, >> >> + and that the descriptor chaining is not only done in the irq/tasklet code >> >> + triggered by the end of the transfer. >> > how is it differenat than current dmaengine semantics where you say >> > issue_pending() is invoked when current transfer finished? Here is you have >> > to do descriptor chaining so bit it. >> Your sentence is a bit difficult for me to understand. > Sorry for typo, meant: > how is it different than current dmaengine semantics where you say > issue_pending() is invoked when current transfer finishes? Here you are > doing descriptor chaining, so be it. It is not "different" from dmaengine semantics. It's an implementation choice which is not strictly required by dmaengine, and therefore a requirement on top of what dmaengine offers. Dmaengine requires to submit a transfer, and gives issue_pending() to provide a guarantee the transfer will be executed. The dmaengine drivers can choose to either queue the transfer when the previous one's completion is notified (interrupt), or hot-queue the transfer while the channel is running. This constraint documents the fact that this specific dmaengine driver's implementation chose to hot-chain transfers whenever possible. > Ideally dmaengine driver should keep submitting txns and opportunistically > based on HW optimize it. All this is transparent to clients, they submit and > wait for callback. True. Yet this is not a requirement, it's a "good design" behavior. I wonder how many dmaengine drivers are behaving in an optimize way ... >> >> + granularity is still descriptor based. >> > This is not pxa specfic >> True. Do you want me to remove the (c) from the document ? > yes Ok, for v3. >> >> + f) Transfer reusability >> >> + An issued and finished transfer should be "reusable". The choice of >> >> + "DMA_CTRL_ACK" should be left to the client, not the dma driver. >> > again how is this pxa specfic, if not documented we should move this to >> > dmaengine documentation >> >> Yes, I agree. I should move this to dmaengine slave documentation, in >> Documentation/dmaengine/provider.txt (in the Misc notes section). Do you want me >> to submit a patch to change the "Undocumented feature" into a properly >> documented feature ? > That would be great On my way, for v3. Cheers. -- Robert