From patchwork Mon Mar 17 09:43:33 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Simon Kagstrom X-Patchwork-Id: 330808 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CBB92C0098 for ; Mon, 17 Mar 2014 20:44:20 +1100 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WPU5Z-000433-L5; Mon, 17 Mar 2014 09:44:09 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WPU5X-0004OH-8H; Mon, 17 Mar 2014 09:44:07 +0000 Received: from ernst.netinsight.se ([194.16.221.21]) by merlin.infradead.org with smtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WPU5T-0004N5-1s for linux-arm-kernel@lists.infradead.org; Mon, 17 Mar 2014 09:44:04 +0000 Received: from marrow.netinsight.se (unverified [10.100.3.78]) by ernst.netinsight.se (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 17 Mar 2014 10:43:33 +0100 Date: Mon, 17 Mar 2014 10:43:33 +0100 From: Simon =?UTF-8?B?S8OlZ3N0csO2bQ==?= To: Russell King - ARM Linux Subject: Re: BUG_ON for DMA-bounce and bidirectional mappings (e100 on IXP4xx) Message-ID: <20140317104333.31e75981@marrow.netinsight.se> In-Reply-To: <20140304123714.7e1fe704@marrow.netinsight.se> References: <20140304112459.354f0980@marrow.netinsight.se> <20140304104528.GQ21483@n2100.arm.linux.org.uk> <20140304123714.7e1fe704@marrow.netinsight.se> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140317_054403_243316_82AD78F8 X-CRM114-Status: GOOD ( 15.87 ) X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [194.16.221.21 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: khalasa@piap.pl, jesse.brandeburg@intel.com, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org Hi again! On Tue, 4 Mar 2014 12:37:14 +0100 Simon Kågström wrote: > On Tue, 4 Mar 2014 10:45:28 +0000 > Russell King - ARM Linux wrote: > > > On Tue, Mar 04, 2014 at 11:24:59AM +0100, Simon Kågström wrote: > > > We have a IXP4xx-based board which has an e100 NIC. During bootup, we > > > trigger a BUG_ON in dmabounce.c because the mapped direction doesn't > > > match the synced one. e100.c maps buffers bidirectional, but the sync > > > is done fromdevice. > > [...] > [...] > And the dma_debug code explicitly skips the check if the direction is > DMA_BIDIRECTIONAL: > > static void check_sync(struct device *dev, > struct dma_debug_entry *ref, > bool to_cpu) > { > [...] > if (entry->direction == DMA_BIDIRECTIONAL) > goto out; > > if (ref->direction != entry->direction) { > err_printk(dev, entry, "DMA-API: device driver syncs " > "DMA memory with different direction " > "[device address=0x%016llx] [size=%llu bytes] " > "[mapped with %s] [synced with %s]\n", > (unsigned long long)ref->dev_addr, entry->size, > dir2name[entry->direction], > dir2name[ref->direction]); > } > [...] > } > > Krzysztofs patch does the same for dmabounce.c, from the dma-debug code > it seems to me that it would make sense there as well? I'd like to bring this issue up again. To me it seems Krzysztofs patch (pasted below again) would align the ARM dmabounce behaviour with the DMA API verifier code. Seems to make sense for my part at least. Comments? // Simon --- a/arch/arm/common/dmabounce.c +++ b/arch/arm/common/dmabounce.c @@ -375,7 +375,7 @@ static int __dmabounce_sync_for_cpu(struct device *dev, dma_addr_t addr, off = addr - buf->safe_dma_addr; - BUG_ON(buf->direction != dir); + BUG_ON(buf->direction != dir && buf->direction != DMA_BIDIRECTIONAL); dev_dbg(dev, "%s: unsafe buffer %p (dma=%#x off=%#lx) mapped to %p (dma=%#x)\n", __func__, buf->ptr, virt_to_dma(dev, buf->ptr), off, @@ -415,7 +415,7 @@ static int __dmabounce_sync_for_device(struct device *dev, dma_addr_t addr, off = addr - buf->safe_dma_addr; - BUG_ON(buf->direction != dir); + BUG_ON(buf->direction != dir && buf->direction != DMA_BIDIRECTIONAL); dev_dbg(dev, "%s: unsafe buffer %p (dma=%#x off=%#lx) mapped to %p (dma=%#x)\n", __func__, buf->ptr, virt_to_dma(dev, buf->ptr), off,