Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2818289pxj; Mon, 14 Jun 2021 07:52:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKleqH1eKTskCRDRJDnRWKaD6i6wxjlTQ1lADVgSYo87zkkfByZP6LBgWLiiFkbNGFOJZ4 X-Received: by 2002:a17:906:5d14:: with SMTP id g20mr15182228ejt.243.1623682357579; Mon, 14 Jun 2021 07:52:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623682357; cv=none; d=google.com; s=arc-20160816; b=N6dT+G513NEb2ZuLqLO7iE7y6GV8TXlbNnXFUufJVlsGDrHy6lWoxTgOEjNTcG0cs9 SqjqxqBDwXtYg+a426XILSxQsNnNKhYqggHSHMpHcWVHDn25UHm1IM8sp6vJHN6+/7pc O7ZLkmvJUBrdxcSfsgFrws/MTDd3Cg8qbEhcPAUgp9rigGGw85TxzEnfolPGSkmixEV9 9aiKotaSs15SiyygEM1wS1YMz9xy3DkZMOba43eKFe3zWoiEk+ddDalQJ5jWXhjMs8EV kT+pNJ+YUgg5ia6VN09Q1KYKIKK4HIQq/rwFIiM7BfH5SVJBLSCmxHArGQrSEJ89kRdX kn6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=+4Qvb4ZQoRFUY2IIVBZu682N/AYpBGRWgx0xG+xqqKI=; b=zvKdSLFyFIeunXveiO1dygRQToekCmPzfha1QwOwP6Hyt9pXCu9MRqxMTg8xNr6gk2 rdOMVcmI26yeB3TCROTV4GVfAfRxBT1qTOkBoHBEND2xePC9Gdjew8JHQn50S+jvQau8 bw0M3m53EtFsQuGei1uzv5GwSbu9m7iwvU617IL5uclncRLxUtvHBX7/ykijEtOMm4M4 48NesJ4H03MVN8D5P0IGyKt22HGh2Oie1aOhFO2vw4atr/fhf2gP9unP/40LdXLJYmY8 NFVUQn8jKU6d2IZ/fhCj5iQPMBVE4H2FvLurVNZ7V/wwqyE34o5f6gYIa2j4c2hjXgCu le4A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w9si1590794edx.526.2021.06.14.07.52.14; Mon, 14 Jun 2021 07:52:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233051AbhFNOxN (ORCPT + 99 others); Mon, 14 Jun 2021 10:53:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:52494 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232852AbhFNOxL (ORCPT ); Mon, 14 Jun 2021 10:53:11 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id A31186128C; Mon, 14 Jun 2021 14:51:07 +0000 (UTC) Date: Mon, 14 Jun 2021 15:51:05 +0100 From: Catalin Marinas To: Dong Aisheng Cc: Will Deacon , Dong Aisheng , iommu@lists.linux-foundation.org, open list , linux-mm@kvack.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Christoph Hellwig , Marek Szyprowski , Robin Murphy Subject: Re: [PATCH 1/1] dma: coherent: check no-map property for arm64 Message-ID: <20210614145105.GC30667@arm.com> References: <20210611131056.3731084-1-aisheng.dong@nxp.com> <20210614083609.GA18701@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 14, 2021 at 06:07:04PM +0800, Dong Aisheng wrote: > On Mon, Jun 14, 2021 at 4:36 PM Will Deacon wrote: > > On Fri, Jun 11, 2021 at 09:10:56PM +0800, Dong Aisheng wrote: > > > Coherent dma on ARM64 also can't work with mapped system ram, > > > that means 'no-map' property must be specified in dts. > > > Add the missing check for ARM64 platforms as well. > > > Besides 'no-map' checking, 'linux,dma-default' feature is also > > > enabled for ARM64 along with this patch. > > > > Please can you explain _why_ it can't work? We don't need to tear down > > aliases from the linear map for the streaming DMA API, so why is this > > case different? Also, coherent devices wouldn't need this either way, > > would they? What problem are you solving here? > > > > Not sure if i get your point correctly. Here is my understanding. (fix > me if wrong) > In current implementation, the coherent dma memory will be remapped as > writecombine and uncached type which can't reuse the linear mapping. > The prerequisite to do this is the memory must not be mapped System RAM. > e.g. reserved memory with no-map property and invisible to the buddy system. The architecture allows the system RAM to be mapped in the linear map while there's another writecombine alias, as long as there are no dirty cache lines that could be evicted randomly. This works fine with the DMA API (and we have some cache maintenance when the non-cacheable mapping is first created). Looking at the rmem_dma_device_init() -> dma_init_coherent_memory(), it ends up calling memremap(MEMREMAP_WC) which would warn if it intersects with system RAM regardless of the architecture. If the memory region is nomap, it doesn't end up as IORESOURCE_SYSTEM_RAM, so memremap() won't warn. But why is this specific only to arm (or arm64)? Is the "shared-dma-pool" property only meant for Normal Non-cacheable memory (hence the MEMREMAP_WC flag)? If a system is fully cache coherent, does this check still make sense or the DT is not supposed to have such nodes? > This seems a little different from CMA which the memory is still > underlying managed by the buddy system in order to support migration. > > The patch here does not resolve a real issue but just open the sanity check for > ARM64 case as well as ARM which reports the issue a little bit earlier at > rmem_dma_setup() time. I think we first need to figure out what the real issue is and then try to solve it. -- Catalin