From patchwork Fri Dec 16 15:00:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Murzin X-Patchwork-Id: 9477987 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EF5C9601C2 for ; Fri, 16 Dec 2016 15:03:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E13BD287B0 for ; Fri, 16 Dec 2016 15:03:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D5357287ED; Fri, 16 Dec 2016 15:03:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7E094287B0 for ; Fri, 16 Dec 2016 15:03:30 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1cHu0U-0007wZ-C0; Fri, 16 Dec 2016 15:01:10 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1cHu0Q-0007tE-EU for linux-arm-kernel@lists.infradead.org; Fri, 16 Dec 2016 15:01:07 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6D34BAD7; Fri, 16 Dec 2016 07:00:44 -0800 (PST) Received: from [10.1.78.251] (e103136-lin.cambridge.arm.com [10.1.78.251]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 488FA3F45C; Fri, 16 Dec 2016 07:00:43 -0800 (PST) Subject: Re: [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU To: Alexandre Torgue , linux-arm-kernel@lists.infradead.org References: <1481636704-18948-1-git-send-email-vladimir.murzin@arm.com> <82f0d72e-7029-ad88-3e44-ab48784297fa@st.com> From: Vladimir Murzin Message-ID: <58540199.6000002@arm.com> Date: Fri, 16 Dec 2016 15:00:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <82f0d72e-7029-ad88-3e44-ab48784297fa@st.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161216_070106_606248_1629E7F8 X-CRM114-Status: GOOD ( 18.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Maxime Coquelin , robin.murphy@arm.com, linux@armlinux.org.uk, benjamin.gaignard@linaro.org, sza@esh.hu Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Alexandre, On 16/12/16 14:57, Alexandre Torgue wrote: > Hi Vladimir, > > On 12/13/2016 02:45 PM, Vladimir Murzin wrote: >> Hi, >> >> It seem that addition of cache support for M-class cpus uncovered >> latent bug in DMA usage. NOMMU memory model has been treated as being >> always consistent; however, for R/M classes of cpu memory can be >> covered by MPU which in turn might configure RAM as Normal >> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and >> friends, since data can stuck in caches now or be buffered. >> >> This patch set is trying to address the issue by providing region of >> memory suitable for consistent DMA operations. It is supposed that such >> region is marked by MPU as non-cacheable. Since we have MPU support in >> Linux for R-class only and M-class setting MPU in bootloader, proposed >> interface to advertise such memory is via "memdma=size@start" command >> line option, to avoid clashing with normal memory (which usually comes >> from dts) it'd be safer to use it together with "mem=" command line >> option. Meanwhile, I'm open to suggestions for the better way telling >> Linux of such memory. >> >> For configuration without cache support (like Cortex-M3/M4) dma >> operations are forced to be coherent and wired with dma-noop. Such >> decision is made based on cacheid global variable. In case cpu >> supports caches and no coherent memory region is given - dma is >> disallowed. Probably, some other important checks are missing, so I'll >> all my ears :) >> >> To make life easier NOMMU dma operations are kept in separate >> compilation unit. >> >> Thanks! >> >> Changelog: >> >> RFC v1 -> RFC v2 >> - s/dmac_unmap_area/dmac_map_area in __dma_page_cpu_to_dev() >> - removed unrelated changes in nommu.c >> >> Vladimir Murzin (3): >> ARM: NOMMU: introduce dma operations for noMMU >> ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus >> ARM: dma-mapping: remove traces of NOMMU code >> >> arch/arm/include/asm/dma-mapping.h | 3 +- >> arch/arm/mm/Kconfig | 2 +- >> arch/arm/mm/Makefile | 5 +- >> arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++ >> arch/arm/mm/dma-mapping.c | 26 +--- >> arch/arm/mm/mm.h | 3 + >> arch/arm/mm/nommu.c | 6 + >> 7 files changed, 278 insertions(+), 29 deletions(-) >> create mode 100644 arch/arm/mm/dma-mapping-nommu.c >> > > First, thanks for this series. > > I tested it on stm32f746 platform. Main issues related to cache and DMA are fixed but I still have an issue using dma_zalloc_alloc API. Allocated memory is not set to zero. > Can you have a look on it please? Thanks for testing! I think following diff should fix dma_zalloc_alloc(): Cheers Vladimir > > Thanks > Alex > > diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c index f92d98a..1f97bb8 100644 --- a/arch/arm/mm/dma-mapping-nommu.c +++ b/arch/arm/mm/dma-mapping-nommu.c @@ -38,6 +38,7 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t size, ptr = (void *)gen_pool_alloc(dma_pool, size); if (ptr) { + memset(ptr, 0, size); *dma_handle = __pa(ptr); dmac_flush_range(ptr, ptr + size); outer_flush_range(__pa(ptr), __pa(ptr) + size);