Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754849AbcKYO3V (ORCPT ); Fri, 25 Nov 2016 09:29:21 -0500 Received: from smtp2-g21.free.fr ([212.27.42.2]:9945 "EHLO smtp2-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754627AbcKYO3H (ORCPT ); Fri, 25 Nov 2016 09:29:07 -0500 Subject: Re: Tearing down DMA transfer setup after DMA client has finished To: Mans Rullgard Cc: Vinod Koul , 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 References: <58356EA8.2010806@free.fr> <20161125045549.GC2698@localhost> From: Mason Message-ID: Date: Fri, 25 Nov 2016 15:28:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 880 Lines: 27 On 25/11/2016 15:12, M?ns Rullg?rd wrote: > Mason writes: > >> On 25/11/2016 12:57, M?ns Rullg?rd wrote: >> >>> The same DMA unit is also used for SATA, which is an off the shelf >>> Designware controller with an in-kernel driver. This interrupt timing >>> glitch can actually explain some intermittent errors I've observed with >>> it. >> >> FWIW, newer chips embed an AHCI controller, with a dedicated >> memory channel. >> >> FWIW2, the HW dev said memory channels are "almost free", and he >> would have no problem giving each device their own private channel >> read/write pair. > > We still need to deal with the existing hardware. Can you confirm that your MBUS driver, in its current form, does not support memcpy-type transfers, which generate two IRQs (one from send agent, one from receive agent)? Do you plan to support that, or is it just too quirky? Regards.