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 3A10DE7C4CB for ; Wed, 4 Oct 2023 14:59:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81C366B0278; Wed, 4 Oct 2023 10:59:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A41A6B027A; Wed, 4 Oct 2023 10:59:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61DAC6B027D; Wed, 4 Oct 2023 10:59:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4B93D6B0278 for ; Wed, 4 Oct 2023 10:59:10 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 04BA9B3970 for ; Wed, 4 Oct 2023 14:59:09 +0000 (UTC) X-FDA: 81308086860.18.AE3D6C3 Received: from sender4-op-o10.zoho.com (sender4-op-o10.zoho.com [136.143.188.10]) by imf08.hostedemail.com (Postfix) with ESMTP id F403216000C for ; Wed, 4 Oct 2023 14:59:07 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=icenowy.me header.s=zmail2 header.b=eR+gxRYU; spf=pass (imf08.hostedemail.com: domain of uwu@icenowy.me designates 136.143.188.10 as permitted sender) smtp.mailfrom=uwu@icenowy.me; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=pass (policy=none) header.from=icenowy.me ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696431548; 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=LdPMaLjHlfUS0gHSy+2qt31lLyAWmRO7wmsNvzL4OAA=; b=6qdkOtW8FErJRqvbazvx8g3wzn3N7ozySRg2J0Dc6JvV74vafbZrAkT3WXo/rhUrKJU39o NcRSH7EpGCXxDcPdn/jmUV6BG1/gaQMfeH9/Ik40iR1hUY3694KbzBNkgDRsqzPW5M3ybG 5bxWLIwT8h8vzkMlsiP9e1F5g9k7Cco= ARC-Authentication-Results: i=2; imf08.hostedemail.com; dkim=pass header.d=icenowy.me header.s=zmail2 header.b=eR+gxRYU; spf=pass (imf08.hostedemail.com: domain of uwu@icenowy.me designates 136.143.188.10 as permitted sender) smtp.mailfrom=uwu@icenowy.me; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=pass (policy=none) header.from=icenowy.me ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1696431548; a=rsa-sha256; cv=pass; b=uNPPD6V2yXBufFA3OT14I0+sYyI6lvSev9VDvHYBjJwUfjKr0yCDntvQiWzu6G7EczuctS TsgUi4fgdBJoaPz0ZD/jjuDsRxcxQpK5NPpGGOcYCHBMkVCYKL2avu7awuFmtRYPDCUgK/ 7i1vOWdtyCJWdzCmob5cJj9M3WSOC0k= ARC-Seal: i=1; a=rsa-sha256; t=1696431543; cv=none; d=zohomail.com; s=zohoarc; b=gMNoEli4g2cQmjpcvCqiTd0zYxrBPMD7THOpvqCJHuBCjFTHlL9bRpK1PpNn9VxWIMRRvOWFj/81OVWtua0txKV9ePNxYJz/s9wa8Qqwc1qR17pt+ONK2llQh9jXO0O5o9UxpU03SAa1SuhE8GBIMYh9hcJmZxEeC1MxpTxWMWQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1696431543; 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=LdPMaLjHlfUS0gHSy+2qt31lLyAWmRO7wmsNvzL4OAA=; b=RndgPiKwFgWEQvELvUjLB4YgihwR+6RtVkQGlc1vQeTytOl0qwkq5Grh5h9Q9vBuNH3GrYJZrJs9ZSIAeB86tKLvEloWPMRDz0OLeCPIvzRfZ1ZFefbdsUggu3U4WAAyjQNBpKAKOZ4d/EhXai85OdmlZj5xQXKqxiKnUt5F3uM= 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=1696431543; 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=LdPMaLjHlfUS0gHSy+2qt31lLyAWmRO7wmsNvzL4OAA=; b=eR+gxRYUfLByktnwDoAwm9lPs4BfVqK07dHUdshqDxQX2gRuSzUu3NFgPnhbxYRc rMLb8eGiorRLyOJ6xgw3daXcyMGY2mq886CEGxS+toWYQzUc2hAtqYhDWbylPy5cyru lULRYYaZaMkWc4UCNNbRIi8ttEPo1CXM5swK74Bcscl9OZ3+MlpilTGcqSMFxaV0HNR VmMkv2V9QlRvVB2a9wjbrBQ02AP5OmGfA642uz3IbHTtbREbkub7MO2+IpvBJ9yECtI PK3T9xtDX4OVUyarYMIkSfRjEgR286oGWKYn3eTMHyjiFuQ29v0YbqYHFSlrN6FjeGg xCr+bBBG+w== Received: from edelgard.fodlan.icenowy.me (120.85.98.65 [120.85.98.65]) by mx.zohomail.com with SMTPS id 1696431540266745.8094566529361; Wed, 4 Oct 2023 07:59:00 -0700 (PDT) Message-ID: <12ea9707f8c45dc398eb20f303aba9ecc7624455.camel@icenowy.me> 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:58:52 +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-Rspamd-Queue-Id: F403216000C X-Rspam-User: X-Stat-Signature: a8y6wqfox8jbd9np4qk4k7dhbm9e9tfe X-Rspamd-Server: rspam01 X-HE-Tag: 1696431547-823608 X-HE-Meta: U2FsdGVkX1+XY/A4KRFWwyKEOrceLOLt7l8BhYJhD23a/LgGwbMfrfRta/s/nj5kvCUs4ZtzngHrjQEGJ1jMg1/3hGw4ZBVyB+c2z5lNk669IKW5yapkTAxQWtE2I1Kv1Sanx4wiT+VdLZdMMZAUODUVglgDtZjeaLnj/1nlfASjMxMJ+24IZU4WPw1HfDp0j4n4b4S6aG+Ypt4GI84DijIN9bpgPeJjSxS0O/mRCOj5z6xLwBwEudhGcT0nddnM2d9HWjlJc39mym+viopHpYRn8G0fYiz9kbWN18E07mWw/P8xSpi3H6VCMSOh033tQlX09WzqG5Z0fhiKHt5VfDLiQl19MofcBP2c2Nzp/EePImcPvRQAOh9joGEkQYVAqAjMqzZDVPP3peV+gLfhj3s6bNzg/Gwthu1BlmXYZloyc9odt1vOgtBTyofvckIII3/fugxbdPhgrrB3abusWauXsishwlBheZHEiZC6PiuLvOcQo9YWndlC1zJsKWuJznG6nPBRkZ+MCEHCw+u6gzOOGJcgl7+c0ZVfW/mj1OwxZQZJBfQL8/zOvTabm2jQ8MttTq45Xp++yCZ8ez1oW6hi4KGeEQq1Z5jZUiMyFGT4LxNlzo1kcHtd8LuaSJnc1kLUZg0aKBfpyimyfawN3OcDCppNLhKCYImZe9mT+LT8uOQNIIOZr1DpFqDc7Wm3c0L5HmO1oQP3ABjIbu5JtWfTqUQp8WocwazQVeVMDwjIfnRgY6xTKdzwe5vypJsZRymrFsqaIAHRike/Tus6T5jmD6Rm+2ZXs4NG8nCwnfK1XNoEfd7AImcFUzfFAb8eOKooMGlIfwXGFe2/FElb0kfKDn4uzTA4+3MI2O1KwtkjbnKaJYYBo+hu08hYzFwHTkSemMpaV/avw9M3KSRpZEHKnTkY2uZ8umDA8NOaLjv8VcUTj4wxKQmFc/iWkdR3eixvkXGGI+PLcRBf9jo 7yxTg1eo utw7FGSVj7H9SWy3xhoyhotnExgb6+hjq6jNdmMLAuuAxH8+1Ap2vIfyGjRyWiuPcd+UJb9nZr0aF4hOtC0UHms5u8ECw1WLq8Urmj+X8U09Ky96UpByfI99OCJ9TRqwP7fPDVYKukU6uBhIhF3JE6RDyqjP+dTaDBPHo/S8vHC2eAtc/c6yHbVpoQsqj9RfbjB88wq0Q0yUCuifLKjdC3XXZz/UwSGG3x5Dqizcow9RKbw70puFFaa8XfuQ/UL1FZ/iy05ku9r1kSjHlY89v+3xN9IRYWk7OJA+tuUbbIeZIIydy/CkVUko+0Zh05Je+fBmOwLHVWn4gejHMjTsksezr0hjJ1LZ9nN1xruNJF5cpcw+f2N0zIV59rBlADNfzdT11ogTv7cPCLXITFOrYqFKB1L4aZLHAOOHfiLseIwO1XdnYMJePf0beLW/FUCfSZ5WtgBY2oMBO7s0= 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 Well, considering RZ/Five enables some spec-non-conformant local memory (which bypasses MMU) that makes even running generic user space binaries not so viable (PIE ones may still run, but those built to be on the default fixed location of binutils will conflict with the MMU- bypassing local memory), not supporting it in a multi-platform kernel doesn't look like a big deal. > 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.