From: Catalin Marinas <catalin.marinas@arm.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: f.fainelli@gmail.com, mbrugger@suse.com, marc.zyngier@arm.com,
robin.murphy@arm.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, robh+dt@kernel.org, wahrenst@gmx.net,
m.szyprowski@samsung.com, linux-riscv@lists.infradead.org,
phill@raspberrypi.org, Will Deacon <will@kernel.org>,
hch@lst.de, linux-arm-kernel@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org
Subject: Re: [PATCH v3 3/4] arm64: use both ZONE_DMA and ZONE_DMA32
Date: Thu, 5 Sep 2019 18:19:39 +0100 [thread overview]
Message-ID: <20190905171939.GF31268@arrakis.emea.arm.com> (raw)
In-Reply-To: <20190902141043.27210-4-nsaenzjulienne@suse.de>
On Mon, Sep 02, 2019 at 04:10:41PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 8956c22634dd..f02a4945aeac 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -50,6 +50,13 @@
> s64 memstart_addr __ro_after_init = -1;
> EXPORT_SYMBOL(memstart_addr);
>
> +/*
> + * We create both ZONE_DMA and ZONE_DMA32. ZONE_DMA covers the first 1G of
> + * memory as some devices, namely the Raspberry Pi 4, have peripherals with
> + * this limited view of the memory. ZONE_DMA32 will cover the rest of the 32
> + * bit addressable memory area.
> + */
> +phys_addr_t arm64_dma_phys_limit __ro_after_init;
> phys_addr_t arm64_dma32_phys_limit __ro_after_init;
>
> #ifdef CONFIG_KEXEC_CORE
> @@ -164,9 +171,9 @@ static void __init reserve_elfcorehdr(void)
> }
> #endif /* CONFIG_CRASH_DUMP */
> /*
> - * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)). It
> - * currently assumes that for memory starting above 4G, 32-bit devices will
> - * use a DMA offset.
> + * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)) and
> + * ZONE_DMA (DMA_BIT_MASK(30)) respectively. It currently assumes that for
> + * memory starting above 4G, 32-bit devices will use a DMA offset.
> */
> static phys_addr_t __init max_zone_dma32_phys(void)
> {
> @@ -174,12 +181,23 @@ static phys_addr_t __init max_zone_dma32_phys(void)
> return min(offset + (1ULL << 32), memblock_end_of_DRAM());
> }
>
> +static phys_addr_t __init max_zone_dma_phys(void)
> +{
> + phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
> +
> + return min(offset + (1ULL << ARCH_ZONE_DMA_BITS),
> + memblock_end_of_DRAM());
> +}
I think we could squash these two functions into a single one with a
"bits" argument that is either 32 or ARCH_ZONE_DMA_BITS.
> +
> #ifdef CONFIG_NUMA
>
> static void __init zone_sizes_init(unsigned long min, unsigned long max)
> {
> unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
>
> +#ifdef CONFIG_ZONE_DMA
> + max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
> +#endif
> #ifdef CONFIG_ZONE_DMA32
> max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma32_phys_limit);
> #endif
> @@ -195,13 +213,17 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
> struct memblock_region *reg;
> unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
> unsigned long max_dma32 = min;
> + unsigned long max_dma = min;
>
> memset(zone_size, 0, sizeof(zone_size));
>
> - /* 4GB maximum for 32-bit only capable devices */
> +#ifdef CONFIG_ZONE_DMA
> + max_dma = PFN_DOWN(arm64_dma_phys_limit);
> + zone_size[ZONE_DMA] = max_dma - min;
> +#endif
> #ifdef CONFIG_ZONE_DMA32
> max_dma32 = PFN_DOWN(arm64_dma32_phys_limit);
> - zone_size[ZONE_DMA32] = max_dma32 - min;
> + zone_size[ZONE_DMA32] = max_dma32 - max_dma;
> #endif
> zone_size[ZONE_NORMAL] = max - max_dma32;
Does this still work if we have ZONE_DMA32 disabled but ZONE_DMA
enabled? You could use a max(max_dma32, max_dma) or just update
max_dma32 to max_dma in the CONFIG_ZONE_DMA block.
> @@ -213,11 +235,17 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>
> if (start >= max)
> continue;
> -
> +#ifdef CONFIG_ZONE_DMA
> + if (start < max_dma) {
> + unsigned long dma_end = min_not_zero(end, max_dma);
> + zhole_size[ZONE_DMA] -= dma_end - start;
> + }
> +#endif
> #ifdef CONFIG_ZONE_DMA32
> if (start < max_dma32) {
> - unsigned long dma_end = min(end, max_dma32);
> - zhole_size[ZONE_DMA32] -= dma_end - start;
> + unsigned long dma32_end = min(end, max_dma32);
> + unsigned long dma32_start = max(start, max_dma);
> + zhole_size[ZONE_DMA32] -= dma32_end - dma32_start;
> }
> #endif
> if (end > max_dma32) {
Similar comment here.
--
Catalin
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2019-09-05 17:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-02 14:10 [PATCH v3 0/4] Raspberry Pi 4 DMA addressing support Nicolas Saenz Julienne
2019-09-02 14:10 ` [PATCH v3 1/4] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() Nicolas Saenz Julienne
2019-09-05 17:05 ` Catalin Marinas
2019-09-02 14:10 ` [PATCH v3 2/4] arm64: rename variables used to calculate ZONE_DMA32's size Nicolas Saenz Julienne
2019-09-05 17:05 ` Catalin Marinas
2019-09-02 14:10 ` [PATCH v3 3/4] arm64: use both ZONE_DMA and ZONE_DMA32 Nicolas Saenz Julienne
2019-09-05 17:19 ` Catalin Marinas [this message]
2019-09-05 17:28 ` Nicolas Saenz Julienne
2019-09-02 14:10 ` [PATCH v3 4/4] mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type' Nicolas Saenz Julienne
2019-09-05 17:21 ` Catalin Marinas
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=20190905171939.GF31268@arrakis.emea.arm.com \
--to=catalin.marinas@arm.com \
--cc=f.fainelli@gmail.com \
--cc=hch@lst.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=m.szyprowski@samsung.com \
--cc=marc.zyngier@arm.com \
--cc=mbrugger@suse.com \
--cc=nsaenzjulienne@suse.de \
--cc=phill@raspberrypi.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=wahrenst@gmx.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).