From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933216AbcLILfX convert rfc822-to-8bit (ORCPT ); Fri, 9 Dec 2016 06:35:23 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:45068 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932478AbcLILfV (ORCPT ); Fri, 9 Dec 2016 06:35:21 -0500 From: 1=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Sebastian Frias Cc: Vinod Koul , Mason , 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 , Thibaud Cornic Subject: Re: Tearing down DMA transfer setup after DMA client has finished In-Reply-To: <6ce1ea97-1d68-2203-c7b4-73315e801655@laposte.net> (Sebastian Frias's message of "Fri, 9 Dec 2016 11:25:57 +0100") References: <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> <20161208163755.GH6408@localhost> <20161209065955.GJ6408@localhost> <6ce1ea97-1d68-2203-c7b4-73315e801655@laposte.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Fri, 09 Dec 2016 11:35:20 +0000 Message-ID: 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 Sebastian Frias writes: > On 09/12/16 07:59, Vinod Koul wrote: >> On Thu, Dec 08, 2016 at 04:48:18PM +0000, Måns Rullgård wrote: >>> Vinod Koul writes: >>> >>>> To make it efficient, disregarding your Sbox HW issue, the solution is >>>> virtual channels. You can delink physical channels and virtual channels. If >>>> one has SW controlled MUX then a channel can service any client. For few >>>> controllers request lines are hard wired so they cant use any channel. But >>>> if you dont have this restriction then driver can queue up many transactions >>>> from different controllers. >>> >>> Have you been paying attention at all? This exactly what the driver >>> ALREADY DOES. >> >> And have you read what the question was? I wrote the driver. I think I know what Mason and I are asking. > I think many people appreciate the quick turn around time and > responsiveness of knowledgeable people making constructive remarks in > this thread, but it looks we are slowly drifting away from the main > problem. > > If we had to sum up the discussion, the current DMA API/framework in > Linux seems to lack a way to properly handle this HW (or if it has a > way, the information got lost somewhere). > > What concrete solution do you propose? > > Alternatively, one can think of the current issue (i.e.: the fact that > the IRQ arrives "too soon") in a different way. Instead of thinking > the IRQ indicates "transfer complete", it is indicating "ready to > accept another command", which in practice (and with proper API > support) can translate into efficient queuing of DMA operations. For multiple back to back transfers to the same peripheral, it is indeed a slight optimisation. What's apparently lacking is some way of doing a full flush at the end of a series of transfers, before switching the channel to another device. -- Måns Rullgård