From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39715E7C4C0 for ; Wed, 4 Oct 2023 14:18:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B84396B0266; Wed, 4 Oct 2023 10:18:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B37046B026B; Wed, 4 Oct 2023 10:18:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D5266B026C; Wed, 4 Oct 2023 10:18:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8C51D6B0266 for ; Wed, 4 Oct 2023 10:18:31 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5799A12020F for ; Wed, 4 Oct 2023 14:18:31 +0000 (UTC) X-FDA: 81307984422.30.B7B9077 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf27.hostedemail.com (Postfix) with ESMTP id 0C9F84002D for ; Wed, 4 Oct 2023 14:18:28 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696429109; a=rsa-sha256; cv=none; b=mXUazKYytB9yvOrxbFo98KsrzEyTjPJ2+bFQV422mNM+NQHVVpC1gKzCWSkInO/uNCovR3 eeZOJBzC4MHZivu+z6rp9Ej187R0ow3lNcLeFv52opgkzK7ECThgxc+AHs7zCoCJ6eB2vD PrB1/BgLIQISmbZf7IxpZCIw6hcL3o4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696429109; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PLk1N4BSEe2UI5Uem9/jBayQvfZVMyA7hfUIdLtmDd0=; b=oCE+Q8ijTaggz9jN1YrA6RHws9cL6QvqH+4Fx6aHMhvOySX+C6ks/okajfbyY/mqtGnTBQ 6KrwouT8xpTisGfs9W1x570Gfb50tdrpzk07xRc2Ff5ts5n76h5sFE4IoM+AgJvni8sHmS k+MNARCK90eBtdXgvCR8lmK21wve8ic= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6C5C7DA7; Wed, 4 Oct 2023 07:19:06 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8454B3F59C; Wed, 4 Oct 2023 07:18:24 -0700 (PDT) Message-ID: Date: Wed, 4 Oct 2023 15:18:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH 0/6] RISC-V: Add eMMC support for TH1520 boards Content-Language: en-GB To: Icenowy Zheng , "Lad, Prabhakar" , Jisheng Zhang Cc: Drew Fustini , Christoph Hellwig , Lad Prabhakar , Robert Nelson , Ulf Hansson , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Adrian Hunter , Guo Ren , Fu Wei , Paul Walmsley , Palmer Dabbelt , Albert Ou , Conor Dooley , Jason Kridner , Xi Ruoyao , Han Gao , linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Alexandre Ghiti , Linux-MM References: <20230921-th1520-mmc-v1-0-49f76c274fb3@baylibre.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0C9F84002D X-Stat-Signature: x8nzkocybx1rgd5kpsokm3c98jj1xks3 X-HE-Tag: 1696429108-937674 X-HE-Meta: U2FsdGVkX18WuBZ/eHe9/7PaMYZxCbFiJV5bXxeiDH4gIRbZWPHMPcGwhD7StcTcTQ2TS9sI5au68zG+8L2Ffnlx1PQTfmhHoaL55MTzFmQqf7LxdAMi+XiPox6yws87UklJV+fmbBSoVhqUWTgCRwbn7uyLwBvHAQHQA3lZMHsq616OGE5c75B36mmd5tMoGq+PEVlZTV/zFhU/yz0VcIJaxJYsudCwygIOVY5NFF2u3w0VA8FPaLv5sYALDX9WP9R651akITukCpXQw0JvXTU2NPZdldLE8lqlCV8ibtMK86mWOK4mONB07bvIBelW6rcmZCG2Na0oEHgzH46lXU8qR0HamBPU3+qWpXpPj1j1hoKNz46WOPr9jueRWh0FlMXF1b8DbaWPeJIlRqKaPfxQ4zPL/FUhHuHidtedX/Axv8v7x3Ek3qGfFNOPf1GHk5tOR9l/mzYQlv6nAXPSgob2sWV42rGtEkZxqiQfNZPiGkrgv+1YbK5jgmG1TC/MEvMsXUKHWEYbSkNBh0U6rSYNR+kDM/CmdYCq97K2ALV+LEKKs3RP/rvgyjnUgHEIBG2yrCkBRMsKa3tjw0vO2EYvqT7mUTHrS0tyTRxEYQUiwhad8OnyKoAXnqTUPPcYo9godWl5yGR97WXTrCCXTZGUGmPtKz2gVkFuLmYTWPEW1hq10LTn4YLkl4MILVO2SfyPxQUH81w2LQSaZY1pOgJIhB4IdlQVbldGeEG0QLty9rsH3pRbVJ4zJHcSTkPqLNDNcxQNAAy+2zKOUWzaL89/+OiBdtqqh9Y/NRE44P1f6OxMk3a8YX8cuNtWViBM5nBzIa5ZYNQw+l1cwcu1CmRTzjCjZn2obOMZugZnwqaKtZeMy8Y9w8EvIYYsX69hKK22BkRFHlKmPWjC1G+ItdRZujOhlqoZ4EHH9Mnp/JNEUarz2Z/wTdT7Xx57PBembA5b5+qUmJXFzYAqLcM CSjix/qM Sp4EekBWmgkkWxbkKnCOf5gLfYwpbO8kA9Du07jK+XdsATYCCKFy1C/YqAfZ/jawjrXAZbvj4DeNNuA3CkdGeKCOpOkAjLz7/NTV/k/MMTYNIzVKV/COMMXPOrCwDPVxkLg3/YlzIB6MOgybrrXv6LOu+giMEjAVwWFRT8rZiQZPEB+JXRUQGtGHzRQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 04/10/2023 3:02 pm, Icenowy Zheng wrote: [...] >>>> I believe commit 484861e09f3e ("soc: renesas: Kconfig: Select the >>>> required configs for RZ/Five SoC") can cause regression on all >>>> non-dma-coherent riscv platforms with generic defconfig. This is >>>> a common issue. The logic here is: generic riscv defconfig >>>> selects >>>> ARCH_R9A07G043 which selects DMA_GLOBAL_POOL, which assumes all >>>> non-dma-coherent riscv platforms have a dma global pool, this >>>> assumption >>>> seems not correct. And I believe DMA_GLOBAL_POOL should not be >>>> selected by ARCH_SOCFAMILIY, instead, only ARCH under some >>>> specific >>>> conditions can select it globaly, for example NOMMU ARM and so >>>> on. >>>> >>>> Since this is a regression, what's proper fix? any suggestion is >>>> appreciated. >> >> I think the answer is to not select DMA_GLOBAL_POOL, since that is >> only > > Well I think for RISC-V, it's not NOMMU only but applicable for every > core that does not support Svpbmt or vendor-specific alternatives, > because the original RISC-V priv spec does not define memory attributes > in page table entries. > > For the Renesas/Andes case I think a pool is set by OpenSBI with > vendor-specific M-mode facility and then passed in DT, and the S-mode > (which MMU is enabled in) just sees fixed memory attributes, in this > case I think DMA_GLOBAL_POOL is needed. Oh wow, is that really a thing? In that case, either you just can't support this platform in a multi-platform kernel, or someone needs to do some fiddly work in dma-direct to a) introduce the notion of an optional global pool, and b) make it somehow cope with DMA_DIRECT_REMAP being enabled but non-functional. Thanks, Robin.