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 EDD61E7C4C8 for ; Wed, 4 Oct 2023 14:47:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74FAC6B0277; Wed, 4 Oct 2023 10:47:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D8596B0278; Wed, 4 Oct 2023 10:47:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 551B26B0279; Wed, 4 Oct 2023 10:47:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 40AFE6B0277 for ; Wed, 4 Oct 2023 10:47:05 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F0B3A80224 for ; Wed, 4 Oct 2023 14:47:04 +0000 (UTC) X-FDA: 81308056368.22.68A3D27 Received: from sender4-op-o10.zoho.com (sender4-op-o10.zoho.com [136.143.188.10]) by imf09.hostedemail.com (Postfix) with ESMTP id E5582140037 for ; Wed, 4 Oct 2023 14:47:02 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=icenowy.me header.s=zmail2 header.b=clD1xuxQ; dmarc=pass (policy=none) header.from=icenowy.me; arc=pass ("zohomail.com:s=zohoarc:i=1"); spf=pass (imf09.hostedemail.com: domain of uwu@icenowy.me designates 136.143.188.10 as permitted sender) smtp.mailfrom=uwu@icenowy.me ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696430823; 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:dkim-signature; bh=U9trAlWX6nBvb4VRniGzCrIKYuNDIMWaTtr2TJttzSk=; b=WZMTXzW7yNOdDOWqjIqT2svASuo82rmwSBdvwNU9953gXOMeZb2IDM9B/UHAjq43o8k67X 2K5W9OIeVC1CrGyRpz5x8l2/mGoULjlR5EHMuY4ae4JgcHHUpUhMYO/pOJHWc1Dvgli/kl wmBEPRWqiMgYcesQAvpCqlrSngeMoMw= ARC-Authentication-Results: i=2; imf09.hostedemail.com; dkim=pass header.d=icenowy.me header.s=zmail2 header.b=clD1xuxQ; dmarc=pass (policy=none) header.from=icenowy.me; arc=pass ("zohomail.com:s=zohoarc:i=1"); spf=pass (imf09.hostedemail.com: domain of uwu@icenowy.me designates 136.143.188.10 as permitted sender) smtp.mailfrom=uwu@icenowy.me ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1696430823; a=rsa-sha256; cv=pass; b=1kWhuQL/zEcQNxFIZ88cSO0G/CcUdZA+2v3+0nudvlX9SdhFBsj1E2+7jReejIfWffA/qE 8Uk6BrtDdEfJQv4kOaiP/zAIh5/1k+i9CsyagFTHBrO1jsL1aBSFJz9tfp7QdmSHP911lX zjFakHvvSe9mgPc+AvvsCjevB3ed7jQ= ARC-Seal: i=1; a=rsa-sha256; t=1696430820; cv=none; d=zohomail.com; s=zohoarc; b=nxDApxEtzlx2xFddY5YqEaRiOelJY8n/5mSNawUGpBG3I4vQC4X6GggHHzTZGSLcLkPGqCZOrc+tkBKbKAd3i06Bbk7F0OUL7UxA76yEowMwZhSJ74h2XX37KOf54puONWX7BIVNHtshOXE/9mI3fxe3FOJu3TJpZ9yeDzplVFw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1696430820; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=U9trAlWX6nBvb4VRniGzCrIKYuNDIMWaTtr2TJttzSk=; b=Pb0xQhHAo1a30Wk3f00tHT5zSAo2GAyeRFIbWiMCxFSbygrlW4OnZkyNQoDbzqLwOwSwyQOebsf6/MlERWP1fwTNGjA2pBlD/OqclMdwf49it/1lzynrNllKQdwiSv5oknBgYLs0vMONzdPCafJAOFvRlkXb15dZE03/+ELxbug= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=icenowy.me; spf=pass smtp.mailfrom=uwu@icenowy.me; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1696430820; s=zmail2; d=icenowy.me; i=uwu@icenowy.me; h=Message-ID:Subject:Subject:From:From:To:To:Cc:Cc:Date:Date:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:MIME-Version:Message-Id:Reply-To; bh=U9trAlWX6nBvb4VRniGzCrIKYuNDIMWaTtr2TJttzSk=; b=clD1xuxQ/rJT7sA7O7drvAgcArpOp3gx//OhNLxCkza9KKFmcbCglsnObwhOrAKZ V4iO/MHUcJIfw+nCFggVYLY0hPT/C/R0nG9HUcMtbRgcQwvxBt6DrPVPLO5xVl4tqj9 t/+YXinXCg+k30aSzalQmTOkomM8b/NVjL5ArW78BBufIWPenKo7XjKK+Gd5iYWtH7H urAHnBNC4SpiQ6QzjUG19BJg3sxcSxZeb0TDa3liQHXmPy/A9Pt8j96RbJlaFoApC/t ug0UzUii4LGLU2jmdXK7JwSwRe6suIbo9t68yzPgI/egoHEWZU+P2ZFIgI34IxpOMjs UfnD+EigcQ== Received: from edelgard.fodlan.icenowy.me (120.85.98.65 [120.85.98.65]) by mx.zohomail.com with SMTPS id 1696430817671586.6852143453285; Wed, 4 Oct 2023 07:46:57 -0700 (PDT) Message-ID: Subject: Re: [PATCH 0/6] RISC-V: Add eMMC support for TH1520 boards From: Icenowy Zheng To: Robin Murphy , "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, =?ISO-8859-1?Q?Bj=F6rn_T=F6pel?= , Alexandre Ghiti , Linux-MM Date: Wed, 04 Oct 2023 22:46:49 +0800 In-Reply-To: References: <20230921-th1520-mmc-v1-0-49f76c274fb3@baylibre.com> Organization: Anthon Open-Source Community Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 MIME-Version: 1.0 X-ZohoMailClient: External X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E5582140037 X-Stat-Signature: gb4zcnudgszo3743ytjx799ogtx3k74s X-HE-Tag: 1696430822-681061 X-HE-Meta: U2FsdGVkX19sBT/dQ/ru1sbFGF3gUr5KyNNkwo9V1J3T5729VfRKV4cqR6IhVT0jPgVls+twUhR6fDtYSeLw/FzWUJKwTCVvRohnEp/SKlxT0wBAvRFB/6T+OR/M35scaiAPtFDWZVTpB5tyLgkqzFCWvZzlWAlQVTvmYbNZjWCS9xm3/N6LW+sD8elU/mcFeoev8BHWCE03gYOTDPKgWFWp0TLqx7Jr9LAmFPKE/WVARG5o7IqEtQZ09ZwoOCGJqQSeuA1PJeDuqK0MclcomBVFaYNH3gzi2c2irIq7zYIXu9W9v4PkRy7ss1QMmhkCNNDa3/Q78g/nNS49+wLVT5vtEGZVsYJ9U5baL3LKIRiko/Rw71+OSpcp3tgNjsPR9YoKY+6rriO1v0L6rzS+evGzEE/PTaS1vzBMq8MYp0GoXazNPefk6maMkYz7jtjYVo0z6gkThmHX/rfep906pwJjoTAUr8LfjfWNH6ydI9Gw81nkaCUp8wgbbaB7OmSR2lt8xPRS14neaxcnOd4WkpF+OjcAZs0gR0WT0k3D5UwKJ37Qug+V1DcdR7mcsd0PGJ38Qi6Ixn4wBtz9uVAL4LAn5k4j7klSL2RakDbZKWnUauB1COKpkZAjh46fCDymbfo6cmETarwkfYgI92Z0NrGhbIepWaPVO30cKYJEbdtlwTHaQdUjkve2CA2iTBBTG6s+pKIIJQsQ69ynGOPAIv3ip2qTht5VOk2LSHblH0Y3xjW8kBkNWfw0fJKOSBXqExmmE2+W3G55tYu4J9IPO5TO0gtP/nsoTGlBO0OElgPzLOpEFsxOPI98w0TuQHDvlLK3gDg9He8wUMupgwqKfwMmv22TBXkEn0guvjU4YmoLFIDAdsYCHpQBQiB+ezQflki/e1r//HOtqeyG+C6UGCnWmhe1abhhQH2Hi1aSmawuAcK53lU/937EiPH/GZeLWhmdUkpSvXMVncwx1/I 5VH7sSoA TtxyZW1Y9P9/D4qoVfon40RxevCY5tTcp4zsSducK+rHD0YKnIHITUfjJEYM09JqTvHi244IvZNBjmwMLDy3BNrvlSAq5v53QLRXQOozKlUAz9YWUz5+6Yu5hrVONug4xKK3aYGQwVjvZGuCjrCZD4SuS/tl1vZkLUO9uVT6m121cyusNzOVvOPVb38bU3ZeHfnaOPr5FRbhZ7UR3tKggKzIL0qC89IUc5uv7eA/cRIshR5aasvJDi/5QLfFRMcPfOrvnK/aqeG2SPc42ellMRZerYCJE/bsOiif9jJluzqHcrK0NjVdZ8JVRLRQlhr+sGltEd+/6O4HuC42Bsi7heT6Kstz4DN015PD54y5wWBFywMxZFzuTWP7b445PKM/mqsogeVwiqXfw2up6u92yzN7ApyYjZftLoK2vayF/Gms/noomhP+sePuQos5fy2YwF02zry51fM3c43c= 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: =E5=9C=A8 2023-10-04=E6=98=9F=E6=9C=9F=E4=B8=89=E7=9A=84 15:18 +0100=EF=BC= =8CRobin Murphy=E5=86=99=E9=81=93=EF=BC=9A > 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. > > > > >=20 > > > > > Since this is a regression, what's proper fix? any suggestion > > > > > is > > > > > appreciated. > > >=20 > > > I think the answer is to not select DMA_GLOBAL_POOL, since that > > > is > > > only > >=20 > > 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. > >=20 > > 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. >=20 > Oh wow, is that really a thing? In that case, either you just can't=20 > support this platform in a multi-platform kernel, or someone needs to > do=20 Emmmm thus RZ/Five should `depends on NONPORTABLE`? > some fiddly work in dma-direct to a) introduce the notion of an > optional=20 > global pool, and b) make it somehow cope with DMA_DIRECT_REMAP being=20 > enabled but non-functional. >=20 > Thanks, > Robin.