[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18267b7a61f.12b26bd91245310.4476663913461696630@linux.beauty>
Date: Thu, 04 Aug 2022 16:17:45 +0900
From: Li Chen <me@...ux.beauty>
To: "Arnd Bergmann" <arnd@...db.de>
Cc: "Catalin Marinas" <catalin.marinas@....com>,
"Will Deacon" <will@...nel.org>,
"Rob Herring" <robh+dt@...nel.org>,
"Frank Rowand" <frowand.list@...il.com>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Li Chen" <lchen@...arella.com>,
"Linux ARM" <linux-arm-kernel@...ts.infradead.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"DTML" <devicetree@...r.kernel.org>,
"Linux-MM" <linux-mm@...ck.org>
Subject: Re: [PATCH 4/4] sample/reserved_mem: Introduce a sample of struct
page and dio support to no-map rmem
Hi Arnd,
---- On Tue, 12 Jul 2022 16:50:46 +0900 Arnd Bergmann wrote ---
> Does your hardware require a fixed address for the buffer? If it can be
> anywhere in memory (or at least within a certain range) but just has to
> be physically contiguous, the normal way would be to use a CMA area
> to allocate from, which gives you 'struct page' backed pages.
CMA does support Direct I/O, but it has its own issue:
It does not guarantee that the memory previously borrowed by the OS will be returned to the device.
We've been plagued by examples like this in the past:
Many other kernel modules/subsystems have already allocated much memory from both non-CMA and CMA memory,
When our DSP driver got probed then, cma_alloc will fail in that non-CMA system memory is not enough
for CMA memory to migrate.
Regards,
Li
Powered by blists - more mailing lists