From: Baruch Siach <baruch@tkos.co.il>
To: Elad Nachman <enachman@marvell.com>
Cc: catalin.marinas@arm.com, will@kernel.org,
thunder.leizhen@huawei.com, bhe@redhat.com,
akpm@linux-foundation.org, yajun.deng@linux.dev,
chris.zjh@huawei.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: mm: Fix SOCs with DDR starting above zero
Date: Wed, 03 Jan 2024 20:47:17 +0200 [thread overview]
Message-ID: <87r0iy45ho.fsf@tarshish> (raw)
In-Reply-To: <20240103170002.1793197-1-enachman@marvell.com>
Hi Elad,
On Wed, Jan 03 2024, Elad Nachman wrote:
> From: Elad Nachman <enachman@marvell.com>
>
> Some SOCs, like the Marvell AC5/X/IM, have a combination
> of DDR starting at 0x2_0000_0000 coupled with DMA controllers
> limited to 31 and 32 bit of addressing.
> This requires to properly arrange ZONE_DMA and ZONE_DMA32 for
> these SOCs, so swiotlb and coherent DMA allocation would work
> properly.
> Change initialization so device tree dma zone bits are taken as
> function of offset from DRAM start, and when calculating the
> maximal zone physical RAM address for physical DDR starting above
> 32-bit, combine the physical address start plus the zone mask
> passed as parameter.
> This creates the proper zone splitting for these SOCs:
> 0..2GB for ZONE_DMA
> 2GB..4GB for ZONE_DMA32
> 4GB..8GB for ZONE_NORMAL
>
> Signed-off-by: Elad Nachman <enachman@marvell.com>
For an alternative approach see
https://lore.kernel.org/all/cover.1703683642.git.baruch@tkos.co.il/
baruch
> ---
> arch/arm64/mm/init.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 74c1db8ce271..8288c778916e 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -115,20 +115,21 @@ static void __init arch_reserve_crashkernel(void)
>
> /*
> * Return the maximum physical address for a zone accessible by the given bits
> - * limit. If DRAM starts above 32-bit, expand the zone to the maximum
> - * available memory, otherwise cap it at 32-bit.
> + * limit. If DRAM starts above 32-bit, expand the zone to the available memory
> + * start limited by the zone bits mask, otherwise cap it at 32-bit.
> */
> static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
> {
> phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
> phys_addr_t phys_start = memblock_start_of_DRAM();
> + phys_addr_t phys_end = memblock_end_of_DRAM();
>
> if (phys_start > U32_MAX)
> - zone_mask = PHYS_ADDR_MAX;
> + zone_mask = phys_start | zone_mask;
> else if (phys_start > zone_mask)
> zone_mask = U32_MAX;
>
> - return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
> + return min(zone_mask, phys_end - 1) + 1;
> }
>
> static void __init zone_sizes_init(void)
> @@ -140,7 +141,16 @@ static void __init zone_sizes_init(void)
>
> #ifdef CONFIG_ZONE_DMA
> acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
> - dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
> + /*
> + * When calculating the dma zone bits from the device tree, subtract
> + * the DRAM start address, in case it does not start from address
> + * zero. This way. we pass only the zone size related bits to
> + * max_zone_phys(), which will add them to the base of the DRAM.
> + * This prevents miscalculations on arm64 SOCs which combines
> + * DDR starting above 4GB with memory controllers limited to
> + * 32-bits or less:
> + */
> + dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL) - memblock_start_of_DRAM());
> zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
> arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
> max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Baruch Siach <baruch@tkos.co.il>
To: Elad Nachman <enachman@marvell.com>
Cc: catalin.marinas@arm.com, will@kernel.org,
thunder.leizhen@huawei.com, bhe@redhat.com,
akpm@linux-foundation.org, yajun.deng@linux.dev,
chris.zjh@huawei.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: mm: Fix SOCs with DDR starting above zero
Date: Wed, 03 Jan 2024 20:47:17 +0200 [thread overview]
Message-ID: <87r0iy45ho.fsf@tarshish> (raw)
In-Reply-To: <20240103170002.1793197-1-enachman@marvell.com>
Hi Elad,
On Wed, Jan 03 2024, Elad Nachman wrote:
> From: Elad Nachman <enachman@marvell.com>
>
> Some SOCs, like the Marvell AC5/X/IM, have a combination
> of DDR starting at 0x2_0000_0000 coupled with DMA controllers
> limited to 31 and 32 bit of addressing.
> This requires to properly arrange ZONE_DMA and ZONE_DMA32 for
> these SOCs, so swiotlb and coherent DMA allocation would work
> properly.
> Change initialization so device tree dma zone bits are taken as
> function of offset from DRAM start, and when calculating the
> maximal zone physical RAM address for physical DDR starting above
> 32-bit, combine the physical address start plus the zone mask
> passed as parameter.
> This creates the proper zone splitting for these SOCs:
> 0..2GB for ZONE_DMA
> 2GB..4GB for ZONE_DMA32
> 4GB..8GB for ZONE_NORMAL
>
> Signed-off-by: Elad Nachman <enachman@marvell.com>
For an alternative approach see
https://lore.kernel.org/all/cover.1703683642.git.baruch@tkos.co.il/
baruch
> ---
> arch/arm64/mm/init.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 74c1db8ce271..8288c778916e 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -115,20 +115,21 @@ static void __init arch_reserve_crashkernel(void)
>
> /*
> * Return the maximum physical address for a zone accessible by the given bits
> - * limit. If DRAM starts above 32-bit, expand the zone to the maximum
> - * available memory, otherwise cap it at 32-bit.
> + * limit. If DRAM starts above 32-bit, expand the zone to the available memory
> + * start limited by the zone bits mask, otherwise cap it at 32-bit.
> */
> static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
> {
> phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
> phys_addr_t phys_start = memblock_start_of_DRAM();
> + phys_addr_t phys_end = memblock_end_of_DRAM();
>
> if (phys_start > U32_MAX)
> - zone_mask = PHYS_ADDR_MAX;
> + zone_mask = phys_start | zone_mask;
> else if (phys_start > zone_mask)
> zone_mask = U32_MAX;
>
> - return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
> + return min(zone_mask, phys_end - 1) + 1;
> }
>
> static void __init zone_sizes_init(void)
> @@ -140,7 +141,16 @@ static void __init zone_sizes_init(void)
>
> #ifdef CONFIG_ZONE_DMA
> acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
> - dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
> + /*
> + * When calculating the dma zone bits from the device tree, subtract
> + * the DRAM start address, in case it does not start from address
> + * zero. This way. we pass only the zone size related bits to
> + * max_zone_phys(), which will add them to the base of the DRAM.
> + * This prevents miscalculations on arm64 SOCs which combines
> + * DDR starting above 4GB with memory controllers limited to
> + * 32-bits or less:
> + */
> + dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL) - memblock_start_of_DRAM());
> zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
> arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
> max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
next prev parent reply other threads:[~2024-01-03 18:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 17:00 [PATCH] arm64: mm: Fix SOCs with DDR starting above zero Elad Nachman
2024-01-03 17:45 ` Will Deacon
2024-01-03 17:45 ` Will Deacon
2024-01-03 18:32 ` Florian Fainelli
2024-01-03 18:32 ` Florian Fainelli
2024-01-04 12:38 ` [EXT] " Elad Nachman
2024-01-04 12:38 ` Elad Nachman
2024-01-04 18:28 ` Florian Fainelli
2024-01-04 18:28 ` Florian Fainelli
2024-01-04 18:34 ` Elad Nachman
2024-01-04 18:34 ` Elad Nachman
2024-01-04 18:37 ` Florian Fainelli
2024-01-04 18:37 ` Florian Fainelli
2024-01-03 18:47 ` Baruch Siach [this message]
2024-01-03 18:47 ` Baruch Siach
2024-01-05 19:21 ` Catalin Marinas
2024-01-05 19: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=87r0iy45ho.fsf@tarshish \
--to=baruch@tkos.co.il \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=chris.zjh@huawei.com \
--cc=enachman@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thunder.leizhen@huawei.com \
--cc=will@kernel.org \
--cc=yajun.deng@linux.dev \
/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.