Re: [PATCH v2] riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB
Paul Walmsley <[email protected]> Sun, 19 Jul 2026 18:55:19 -0600 (MDT)
| Newsgroups | dev.linux.lists.spacemit,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi Troy, Anirudh, a few questions - On Tue, 14 Jul 2026, Anirudh Srinivasan wrote: > On Wed, Apr 29, 2026 at 07:41:54PM +0800, Troy Mitchell wrote: > > On RISC-V platforms where the entire physical memory (DRAM) resides > > above the 32-bit address space (i.e., above dma32_phys_limit), the > > current SWIOTLB initialization logic fails. Is this primarily for the SpacemiT K3? Or are there other platforms that this fixes? > > This patch addresses two interconnected issues on such platforms: > > > > 1. Incorrect 32-bit DMA bounce assumption: > > The existing condition `max_pfn > PFN_DOWN(dma32_phys_limit)` assumes > > that a 32-bit DMA bounce buffer is required simply because the maximum > > PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB, > > no memory exists below the limit to satisfy this allocation. Fix > > this by adding a check to ensure `memblock_start_of_DRAM()` is actually > > below the 32-bit limit before enforcing 32-bit SWIOTLB. > > > > 2. kmalloc() bounce buffer allocation failure on non-coherent systems: > > For non-coherent hardware, a bounce buffer is still mandatory for > > cache-line-aligned kmalloc(), even if 32-bit DMA bouncing is skipped. I'm not sure I'm parsing this correctly. Shouldn't this read "for *non*-cache-aligned kmalloc()" ? Or am I missing the point? - Paul