Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965708AbcKXORY convert rfc822-to-8bit (ORCPT ); Thu, 24 Nov 2016 09:17:24 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:40416 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965062AbcKXORX (ORCPT ); Thu, 24 Nov 2016 09:17:23 -0500 From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Mason Cc: dmaengine@vger.kernel.org, Vinod Koul , 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 , Russell King Subject: Re: Tearing down DMA transfer setup after DMA client has finished References: <58356EA8.2010806@free.fr> <58358E79.5050404@free.fr> <5836C69A.3030309@free.fr> Date: Thu, 24 Nov 2016 14:17:18 +0000 In-Reply-To: <5836C69A.3030309@free.fr> (Mason's message of "Thu, 24 Nov 2016 11:53:14 +0100") 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: 2674 Lines: 79 Mason writes: >>> I'm confused. Are you saying there is no solution to my problem >>> within the existing DMA framework? >>> >>> In its current form, the tangox-dma.c driver will fail randomly >>> for writes to a device (SATA, NFC). >>> >>> Maybe an extra hook can be added to the DMA framework? >>> >>> I'd like to hear from the framework's maintainers. Perhaps they >>> can provide some guidance. >> >> You could have the dma descriptor callback wait for the receiving device >> to finish. Bear in mind this runs from a tasklet, so it's not allowed >> to sleep. > > Thanks for the suggestion, but I don't think it works :-( > > This is my DMA desc callback: > > static void tango_dma_callback(void *arg) > { > printk("%s from %pf\n", __func__, __builtin_return_address(0)); > mdelay(10000); > printk("DONE FAKE SPINNING\n"); > complete(arg); > } > > I also added > printk("%s from %pf\n", __func__, __builtin_return_address(0)); > after tangox_dma_pchan_detach(pchan); > > And I get this output: > > [ 35.085854] SETUP DMA > [ 35.088272] START NAND TRANSFER > [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq > [ 35.096882] tango_dma_callback from vchan_complete > [ 45.102513] DONE FAKE SPINNING > > So the IRQ rolls in, the ISR calls tangox_dma_pchan_start, > which calls tangox_dma_pchan_detach to tear down the sbox > setup; and only sometime later does the DMA framework call > my callback function. Yes, I realised this soon after I said it. The dma driver could be rearranged to make it work though. > So far, the work-arounds I've tested are: > > 1) delay sbox tear-down by 10 ?s in tangox_dma_pchan_detach. > 2) statically setup sbox in probe, and never touch it henceforth. > > WA1 is fragile, it might break for devices other than NFC. > WA2 is what I used when I wrote the NFC driver. > > Can tangox_dma_irq() be changed to have the framework call > the client's callback *before* tangox_dma_pchan_start? > > (Thinking out loud) The DMA_PREP_INTERRUPT requests that the > DMA framework invoke the callback from tasklet context, > maybe a different flag DMA_PREP_INTERRUPT_EX can request > calling the call-back directly from within the ISR? > > (Looking at existing flags) Could I use DMA_CTRL_ACK? > Description sounds like some kind hand-shake between > client and dmaengine. > > Grepping for DMA_PREP_INTERRUPT, I don't see where the framework > checks that flag to spawn the tasklet? Or is that up to each > driver individually? Those flags all have defined meanings and abusing them for other things is a bad idea. As far as possible, device drivers should work with any dma driver. -- M?ns Rullg?rd