Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932503AbcLHMmW (ORCPT ); Thu, 8 Dec 2016 07:42:22 -0500 Received: from smtp5-g21.free.fr ([212.27.42.5]:46534 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932115AbcLHMmU (ORCPT ); Thu, 8 Dec 2016 07:42:20 -0500 Subject: Re: Tearing down DMA transfer setup after DMA client has finished To: Mans Rullgard , Geert Uytterhoeven Cc: Vinod Koul , Russell King , dmaengine@vger.kernel.org, Linus Walleij , Dan Williams , LKML , Linux ARM , Jon Mason , Mark Brown , Lars-Peter Clausen , Lee Jones , Laurent Pinchart , Arnd Bergmann , Maxime Ripard , Dave Jiang , Peter Ujfalusi , Bartlomiej Zolnierkiewicz , Sebastian Frias , Thibaud Cornic , Thomas Gambier References: <58356EA8.2010806@free.fr> <20161125045549.GC2698@localhost> <092f44ee-4560-be17-25f7-00948dba3cfa@free.fr> <20fc9020-7278-bc2f-2a8d-43aff5cabff8@free.fr> <20161206051222.GQ6408@localhost> <5846B237.8060409@free.fr> <20161207164341.GX6408@localhost> <20161208103921.GC6408@localhost> From: Mason Message-ID: Date: Thu, 8 Dec 2016 13:41:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 SeaMonkey/2.47 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Language: Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1046 Lines: 26 On 08/12/2016 13:20, M?ns Rullg?rd wrote: > The only problem we have is that nobody envisioned hardware where the > dma engine indicates completion slightly too soon. I suspect there's a > fifo or such somewhere, and the interrupt is triggered when the last > byte has been placed in the fifo rather than when it has been removed > which would have been more correct. As I (tried to) explain here: https://marc.info/?l=dmaengine&m=148007808418242&w=2 A *read* MBUS agent raises its IRQ when it is safe for the memory to be overwritten (i.e. every byte has been pushed into the pipe). A *write* MBUS agent raises its IRQ when it is safe for another agent to read any one of the transferred bytes. The issue comes from the fact that, for a memory-to-device transfer, the system will receive the read agent's IRQ, but most devices (NFC, SATA) don't have an IRQ line to signal that their part of the operation is complete. As I explained, if one sets up a memory-to-memory DMA copy, then the system will actually receive *two* IRQs. Regards.