All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.