Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751392AbaLEOrM (ORCPT ); Fri, 5 Dec 2014 09:47:12 -0500 Received: from mail-gw2-out.broadcom.com ([216.31.210.63]:44577 "EHLO mail-gw2-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751046AbaLEOrK (ORCPT ); Fri, 5 Dec 2014 09:47:10 -0500 X-IronPort-AV: E=Sophos;i="5.07,522,1413270000"; d="scan'208";a="52369475" Message-ID: <5481C567.9040108@broadcom.com> Date: Fri, 5 Dec 2014 15:47:03 +0100 From: Arend van Spriel User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.24) Gecko/20111103 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: Hante Meuleman CC: Russell King - ARM Linux , Will Deacon , Marek Szyprowski , "linux-arm-kernel@lists.infradead.org" , David Miller , "linux-kernel@vger.kernel.org" , brcm80211-dev-list , linux-wireless Subject: Re: using DMA-API on ARM References: <5481794E.4050406@broadcom.com> <20141205094507.GP11285@n2100.arm.linux.org.uk> <20141205122423.GK1630@arm.com> <20141205132332.GS11285@n2100.arm.linux.org.uk> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/05/14 15:20, Hante Meuleman wrote: > Ok, I'll add the necessary debug to get all the information out, > but it will take some time to get it done, so I won't have anything > before Monday. > > -----Original Message----- > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk] > Sent: vrijdag 5 december 2014 14:24 > To: Hante Meuleman > Cc: Will Deacon; Arend Van Spriel; Marek Szyprowski; linux-arm-kernel@lists.infradead.org; David Miller; linux-kernel@vger.kernel.org; brcm80211-dev-list; linux-wireless > Subject: Re: using DMA-API on ARM > > Please wrap your message - replying to a message which looks like this in > my editor is far from easy, and gives me much more work to /manually/ > reformat it before I can reply to it: That's what happens with corporate IT forcing to use Outlook. We can workaround that using Thunderbird on Citrix. I will enlighten Hante about that option :-) Regards, Arend > On Fri, Dec 05, 2014 at 12:56:45PM +0000, Hante Meuleman wrote: >> The problem is with data coming from device, so DMA from device to host. The $ >> >> However: this indicates that dma_alloc_coherent on an ARM target may result i$ >> >> Regards, >> Hante > > Thanks. > > On Fri, Dec 05, 2014 at 12:56:45PM +0000, Hante Meuleman wrote: >> However: this indicates that dma_alloc_coherent on an ARM target may >> result in a memory buffer which can be cached which conflicts with >> the API of this function. > > If the memory has an alias which is cacheable, it is possible for cache > lines to get allocated via that alias, even if the alias has no explicit > accesses to it. > > This is something which I've been going on for quite literally /years/ - > mismatched cache attributes can cause unpredictable behaviour. I've had > a lot of push back from people who are of the opinion that "if it works > for me, then there isn't a problem" and I eventually gave up fighting > the battle, especially as the ARM architecture people weakened my > reasoning behind it by publishing a relaxation of the "no differing > attributes" issue. This was particularly true of those who wanted to > use ioremap() on system memory - and cases such as > dma_init_coherent_memory(). > > So, I never fixed this problem in the original DMA allocator code; I > basically gave up with it. It's a latent bug which did need to be fixed, > and is still present today in the non-CMA case. > > The symptoms which you are reporting sound very much like this kind of > problem - the virtual address for the memory returned by > dma_alloc_coherent() will not be cacheable memory - it will have been > remapped using map_vm_area(). However, there could very well be a fully > cacheable lowmem mapping of that memory, which if a read (speculative or > otherwise) will bring a cache line in, and because the caches are VIPT > or PIPT, that cache line can be hit via the non-cacheable mapping too. > > What I /really/ need is more evidence of this to tell those disbelievers > where to stick their flawed arguments. :) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/