From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Chen Zhou <chenzhou10@huawei.com>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Subject: Re: [PATCH] arm64: Remove arm64_dma32_phys_limit and its uses
Date: Mon, 11 Jan 2021 16:57:08 +0000 [thread overview]
Message-ID: <20210111165707.GA17941@gaia> (raw)
In-Reply-To: <20210107184032.11815-1-catalin.marinas@arm.com>
On Thu, Jan 07, 2021 at 06:40:32PM +0000, Catalin Marinas wrote:
> With the introduction of a dynamic ZONE_DMA range based on DT or IORT
> information, there's no need for CMA allocations from the wider
> ZONE_DMA32 since on most platforms ZONE_DMA will cover the 32-bit
> addressable range. Remove the arm64_dma32_phys_limit and set
> arm64_dma_phys_limit to cover the smallest DMA range required on the
> platform. CMA allocation and crashkernel reservation now goes in
> the dynamically sized ZONE_DMA.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Cc: Chen Zhou <chenzhou10@huawei.com>
> ---
>
> This patch goes on top of the ARCH_LOW_ADDRESS_LIMIT fix from Nicolas,
> already in the arm64 for-next/fixes which fixes a 5.5 issue with
> !CONFIG_ZONE_DMA. The changes here depend on the patches in 5.11-rc1.
> While they look mostly like clean-ups, they still fix a potential issue
> with !CONFIG_ZONE_DMA32 configurations where arm64_dma32_phys_limit
> would be equal to PHYS_MASK but we still have a limited ZONE_DMA. In
> addition, it now allows proper CMA and crashkernel reservations for
> RPi4.
[...]
> @@ -394,16 +399,9 @@ void __init arm64_memblock_init(void)
>
> early_init_fdt_scan_reserved_mem();
>
> - if (IS_ENABLED(CONFIG_ZONE_DMA32))
> - arm64_dma32_phys_limit = max_zone_phys(32);
> - else
> - arm64_dma32_phys_limit = PHYS_MASK + 1;
> -
> reserve_elfcorehdr();
>
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> -
> - dma_contiguous_reserve(arm64_dma32_phys_limit);
> }
>
> void __init bootmem_init(void)
> @@ -438,6 +436,11 @@ void __init bootmem_init(void)
> sparse_init();
> zone_sizes_init(min, max);
>
> + /*
> + * Reserve the CMA area after arm64_dma_phys_limit was initialised.
> + */
> + dma_contiguous_reserve(arm64_dma_phys_limit);
Prior to this patch, disabling CONFIG_ZONE_DMA32 leads to CMA allocation
from the whole RAM as arm64_dma32_phys_limit becomes PHYS_MASK+1. With
this patch (which I plan to merge in 5.11-rc4), we limit the CMA
allocation to the 32-bit addressable RAM (if any) even if we don't
describe anything in DT or IORT since ZONE_DMA is capped at 32-bit. We
could relax this so that ZONE_DMA can be expanded beyond 32-bit with
ZONE_DMA32 disabled and no DT/IORT information. Is there a real use-case
for such configuration? We might as well make ZONE_DMA depend on
ZONE_DMA32 (though given the EXPERT dependency, people should know what
they are doing...).
An alternative would be to change max_zone_phys() to avoid the U32_MAX
cap if ZONE_DMA32 is disabled but I don't think it's worth as I don't
see much point in a kernel config with ZONE_DMA enabled and ZONE_DMA32
disabled.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-11 16:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 18:40 [PATCH] arm64: Remove arm64_dma32_phys_limit and its uses Catalin Marinas
2021-01-11 16:57 ` Catalin Marinas [this message]
2021-01-11 17:35 ` Nicolas Saenz Julienne
2021-01-11 19:04 ` Nicolas Saenz Julienne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210111165707.GA17941@gaia \
--to=catalin.marinas@arm.com \
--cc=chenzhou10@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nsaenzjulienne@suse.de \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.