Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754781AbcKYNut convert rfc822-to-8bit (ORCPT ); Fri, 25 Nov 2016 08:50:49 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:42292 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754419AbcKYNuj (ORCPT ); Fri, 25 Nov 2016 08:50:39 -0500 From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Russell King - ARM Linux Cc: Vinod Koul , Mason , Lars-Peter Clausen , Dave Jiang , Arnd Bergmann , Mark Brown , Linus Walleij , Bartlomiej Zolnierkiewicz , LKML , Laurent Pinchart , dmaengine@vger.kernel.org, Dan Williams , Jon Mason , Lee Jones , Maxime Ripard , Linux ARM Subject: Re: Tearing down DMA transfer setup after DMA client has finished References: <58356EA8.2010806@free.fr> <20161125045549.GC2698@localhost> <20161125124528.GJ14217@n2100.armlinux.org.uk> <20161125133436.GK14217@n2100.armlinux.org.uk> Date: Fri, 25 Nov 2016 13:50:35 +0000 In-Reply-To: <20161125133436.GK14217@n2100.armlinux.org.uk> (Russell King's message of "Fri, 25 Nov 2016 13:34:36 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4770 Lines: 95 Russell King - ARM Linux writes: > On Fri, Nov 25, 2016 at 01:07:05PM +0000, M?ns Rullg?rd wrote: >> Russell King - ARM Linux writes: >> >> > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote: >> >> Looking at thread and discussion now, first thinking would be to ensure >> >> the transaction is completed properly and then isr fired. You may need >> >> to talk to your HW designers to find a way for that. It is quite common >> >> that DMA controllers will fire and complete whereas the transaction is >> >> still in flight. >> >> >> >> If that is not doable, then since you claim this is custom part which >> >> other vendors wont use (hope we are wrong down the line), then we can >> >> have a custom api, >> >> >> >> foo_sbox_configure(bool enable, ...); >> >> >> >> This can be invoked from NFC driver when required for configuration and >> >> teardown. For very specific cases where people need some specific >> >> configuration we do allow custom APIs. >> >> >> >> Only problem with that would be it wont be a generic solution and you >> >> seem to be fine with that. >> > >> > Isn't this just the same problem as PL08x or any other system which >> > has multiple requests from devices, but only a limited number of >> > hardware channels - so you have to route the request signals to the >> > appropriate hardware channels according to the requests queued up? >> > >> > If so, no new "custom" APIs are required, it's already able to be >> > solved within the DMA engine drivers... >> >> That isn't the problem. The multiplexing of many devices on a limited >> number of hardware channels is working fine. The problem is that (some) >> client devices need the routing to remain for some time after the dma >> interrupt signals completion. I'd characterise this hardware as broken, >> but there's nothing we can do about that. >> >> The fix has to provide some way for the dma driver to delay reusing a >> hardware channel until the client device indicates completion. If only >> a short delay (a few bus cycles) is needed, it is probably acceptable to >> rework the driver such that the descriptor completion callback can do >> the necessary waiting (e.g. by busy-polling a device status register). >> If the delay can be longer, some other method needs to be devised. > > What I understood from the original mail is: > > | The problem is that the DMA driver tears down the sbox setup > | as soon as it receives the IRQ. However, when writing to the > | device, the interrupt only means "I have pushed all data from > | memory to the memory channel". These data have not reached > | the device yet, and may still be "in flight". Thus the sbox > | setup can only be torn down after the NFC is idle. > > The interrupt comes in after it's read the the last data from memory, > but the data is still sitting in the engine's buffers and has not yet > been passed to the device. > > It sounds like the DMA engine buffers the data on its way to the device, > and it's not clear from the description whether that is done in > response to a request from the device or whether the data is prefetched. > IOW, what the lifetime of the data in the dma engine is. It's not clear from the information I have exactly when the interrupt fires, only that it appears to be somewhat too early. > It seems odd that the DMA engine provides no way to know whether the > channel still contains data that is in-flight to the device, whether > by interrupt (from the descriptions the IRQ is way too early) or by > polling some status register within the DMA engine itself. > > If the delay is predictable, why not use a delayed workqueue or a > hrtimer to wait a period after the IRQ before completing the DMA > transaction? If it's not predictable and you haven't some status > register in the DMA engine hardware that indicates whether there's > remaining data, then the design really is screwed up, and I don't > think there's a reasonable solution to the problem - anything > would be a horrid hack that would be specific to this SoC. This would hardly be the first screwed up hardware design. There is a completion indicator, just not in the dma engine. For some idiotic reason, the designers put this responsibility on the client devices and their respective drivers. > It would be unfair to augment the API and add the burden on everyone > for the new API when 99.999% of the world doesn't require it. I don't think making this particular dma driver wait for the descriptor callback to return before reusing a channel quite amounts to a horrid hack. It certainly wouldn't burden anyone other than the poor drivers for devices connected to it, all of which are specific to Sigma AFAIK. -- M?ns Rullg?rd