[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <be4e43b676ca5619e99b0f5abf228e45fadedb70.camel@icenowy.me>
Date: Wed, 04 Oct 2023 22:46:49 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Robin Murphy <robin.murphy@....com>,
"Lad, Prabhakar" <prabhakar.csengg@...il.com>,
Jisheng Zhang <jszhang@...nel.org>
Cc: Drew Fustini <dfustini@...libre.com>,
Christoph Hellwig <hch@....de>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
Robert Nelson <robertcnelson@...il.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Conor Dooley <conor@...nel.org>,
Jason Kridner <jkridner@...gleboard.org>,
Xi Ruoyao <xry111@...111.site>, Han Gao <gaohan@...as.ac.cn>,
linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
Björn Töpel <bjorn@...nel.org>,
Alexandre Ghiti <alexghiti@...osinc.com>,
Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH 0/6] RISC-V: Add eMMC support for TH1520 boards
在 2023-10-04星期三的 15:18 +0100,Robin Murphy写道:
> 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
Emmmm thus RZ/Five should `depends on NONPORTABLE`?
> 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.
Powered by blists - more mailing lists