From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D0951B266 for ; Wed, 4 Oct 2023 16:04:06 +0000 (UTC) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78F94D7; Wed, 4 Oct 2023 09:04:04 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-496d3e18f19so4420e0c.2; Wed, 04 Oct 2023 09:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696435443; x=1697040243; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MABqfnWSdAh1rkdR5ORe/BqnN4/f/y3PtSz94ONAKI4=; b=LjSut4t1cnfDnGSXSwLhY061TRdkVHDsJwmFsEwsOT7/K5L5A7wBxWtCK9lZ47o6Oq n12FtYl4KruRwOSXk2CSd5SKuKuodTk6zaRqplngDQ3bjF1w7rg9flSYSJsQ3encgAZA rCrF404dq7drul805knb8QQwqTTGXyskXPMUiK+j66D6++vbtIsf4ByOeR86BFkR7IaC HqRGIlRMS9NVw3EqZedecraSAJ10K11OEMcfQOuu2vRuQX6iLzt0FyqREkTe0idWac+U MZQ2fuNHdd+9k7NBgGTkshTt6fYXsZAEXBnKI9dh6s3OyKtNSbhSMO5MBt5cz0y0oNlJ EgEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696435443; x=1697040243; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MABqfnWSdAh1rkdR5ORe/BqnN4/f/y3PtSz94ONAKI4=; b=Wp3YGeEzSX27zDxmozlkHVac33F47CBbX1vI56SHLsZ0X0IZeGJ926htapXZiiHFp4 MKo8+kI8GxTCxu66a3b0u/sh7v2ry5SBL3Bk6eOabtWYiAxlPEGpTbEPvZnA3BIMgWd4 XwxRWlbGWBuxCAsi2lSwn7QzSGpw3CAoyj6YcfrTVeBes2pLlJRygh8i7SniuC6zGOGY FDMYpUxUC42ZB8d0qjAqIpBOR55hQn4uTMoVTTGOd53S5/x/V940/63peB+3QtYzVdvL hAcODmRnAtuKY69sQt0p6x0gZ2l1yMPcz+sbObIXkx40M3aT3ImBQb9/w02WzZc0X+Kp R5sg== X-Gm-Message-State: AOJu0Yy2FVoULxH72Ll8WUy3Or/yHhJ3LyprpbbRRghScMtsj3Gex0dp p6JVt/RWPEIVAUOxctZZ27qA95XgDF5uW8nSGv8= X-Google-Smtp-Source: AGHT+IFhqTAHYHSaLhsynlzcRRRkFceUfAS3vdmJwZJTjrHm3e3CkHq0mrE5OVpqiZHY9FG2KMkgJe29WNiyo850cMc= X-Received: by 2002:a1f:4ac2:0:b0:49a:3537:881e with SMTP id x185-20020a1f4ac2000000b0049a3537881emr2263379vka.13.1696435443340; Wed, 04 Oct 2023 09:04:03 -0700 (PDT) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20230921-th1520-mmc-v1-0-49f76c274fb3@baylibre.com> In-Reply-To: From: "Lad, Prabhakar" Date: Wed, 4 Oct 2023 17:03:36 +0100 Message-ID: Subject: Re: [PATCH 0/6] RISC-V: Add eMMC support for TH1520 boards To: Robin Murphy Cc: Geert Uytterhoeven , Arnd Bergmann , Icenowy Zheng , Jisheng Zhang , 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 , Fabrizio Castro Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Wed, Oct 4, 2023 at 3:18=E2=80=AFPM Robin Murphy = wrote: > > 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, Looking at the code [0] we do have compile time check for CONFIG_DMA_GLOBAL_POOL irrespective of this being present in DT or not, instead if we make it compile time and runtime check ie either check for DT node or see if pool is available and only then proceed for allocation form this pool. What are your thoughts on this? [0] https://elixir.bootlin.com/linux/v6.6-rc4/source/kernel/dma/direct.c#L2= 38 > and b) make it somehow cope with DMA_DIRECT_REMAP being > enabled but non-functional. > DMA_DIRECT_REMAP config option is selected by NONCOHERENET config option an= yway. Cheers, Prabhakar