Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754575AbcKYNHj convert rfc822-to-8bit (ORCPT ); Fri, 25 Nov 2016 08:07:39 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:42130 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754628AbcKYNHU (ORCPT ); Fri, 25 Nov 2016 08:07:20 -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> Date: Fri, 25 Nov 2016 13:07:05 +0000 In-Reply-To: <20161125124528.GJ14217@n2100.armlinux.org.uk> (Russell King's message of "Fri, 25 Nov 2016 12:45:29 +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: 2115 Lines: 45 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. -- M?ns Rullg?rd