Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932219AbcLHMDz (ORCPT ); Thu, 8 Dec 2016 07:03:55 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:36172 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752308AbcLHMDx (ORCPT ); Thu, 8 Dec 2016 07:03:53 -0500 MIME-Version: 1.0 In-Reply-To: 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> <91b0d10c-1bc2-c3e1-4088-f4ad9adcd6c0@free.fr> From: Geert Uytterhoeven Date: Thu, 8 Dec 2016 13:03:51 +0100 X-Google-Sender-Auth: 2vMMshu3svzu6rRBj3yZj3RMnkY Message-ID: Subject: Re: Tearing down DMA transfer setup after DMA client has finished To: =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= Cc: Mason , 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uB8C46Cn020209 Content-Length: 2618 Lines: 65 Hi Måns, On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård wrote: > Geert Uytterhoeven writes: >> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote: >>> On 08/12/2016 11:39, Vinod Koul wrote: >>>> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote: >>>>> Vinod Koul writes: >>>>>> On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote: >>>>>>> That's not going to work very well. Device drivers typically request >>>>>>> dma channels in their probe functions or when the device is opened. >>>>>>> This means that reserving one of the few channels there will inevitably >>>>>>> make some other device fail to operate. >>>>>> >>>>>> No that doesn't make sense at all, you should get a channel only when you >>>>>> want to use it and not in probe! >>>>> >>>>> Tell that to just about every single driver ever written. >>>> >>>> Not really, few do yes which is wrong but not _all_ do that. >>> >>> Vinod, >>> >>> Could you explain something to me in layman's terms? >>> >>> I have a NAND Flash Controller driver that depends on the >>> DMA driver under discussion. >>> >>> Suppose I move the dma_request_chan() call from the driver's >>> probe function, to the actual DMA transfer function. >>> >>> I would want dma_request_chan() to put the calling thread >>> to sleep until a channel becomes available (possibly with >>> a timeout value). >>> >>> But Maxime told me dma_request_chan() will just return >>> -EBUSY if no channels are available. >>> >>> Am I supposed to busy wait in my driver's DMA function >>> until a channel becomes available? >> >> Can you fall back to PIO if requesting a channel fails? >> >> Alternatively, dma_request_chan() could always succeed, and >> dmaengine_prep_slave_sg() could fail if the channel is currently not >> available due to a limitation on the number of active channels, and >> the driver could fall back to PIO for that transfer. > > Why are we debating this nonsense? There is an easy fix that doesn't > require changing the semantics of existing functions or falling back to > slow pio. You still want to fall back to PIO if the DMA engine is not available at all (e.g. DMA engine driver not compiled in, or module not loaded). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds