| Message ID | 20190731154752.16557-6-nsaenzjulienne@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Raspberry Pi 4 DMA addressing support | expand |
On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote: > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index 1c4ffabbe1cb..f5279ef85756 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 might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed if there > + * are periferals unable to address the first naturally aligned 4GB of ram. > + * ZONE_DMA32 will be expanded to cover the rest of that memory. If such > + * limitations doesn't exist only ZONE_DMA32 is created. > + */ Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back onto ZONE_DMA32?
On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote: > On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote: > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > index 1c4ffabbe1cb..f5279ef85756 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 might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed if > > there > > + * are periferals unable to address the first naturally aligned 4GB of ram. > > + * ZONE_DMA32 will be expanded to cover the rest of that memory. If such > > + * limitations doesn't exist only ZONE_DMA32 is created. > > + */ > > Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit > range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back > onto ZONE_DMA32? Hi Catalin, thanks for the review. You're right, the GFP_DMA page allocation will fail with a nasty dmesg error if ZONE_DMA is configured but empty. Unsurprisingly the opposite situation is fine (GFP_DMA32 with an empty ZONE_DMA32). I switched to the scheme you're suggesting for the next version of the series. The comment will be something the likes of this: /* * We create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA's size is decided based * on whether the SoC's peripherals are able to address the first naturally * aligned 4 GB of ram. * * If limited, ZONE_DMA covers that area and ZONE_DMA32 the rest of that 32 bit * addressable memory. * * If not ZONE_DMA is expanded to cover the whole 32 bit addressable memory and * ZONE_DMA32 is left empty. */ Regards, Nicolas
On 2019-08-01 4:44 pm, Nicolas Saenz Julienne wrote: > On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote: >> On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote: >>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >>> index 1c4ffabbe1cb..f5279ef85756 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 might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed if >>> there >>> + * are periferals unable to address the first naturally aligned 4GB of ram. >>> + * ZONE_DMA32 will be expanded to cover the rest of that memory. If such >>> + * limitations doesn't exist only ZONE_DMA32 is created. >>> + */ >> >> Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit >> range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back >> onto ZONE_DMA32? > > Hi Catalin, thanks for the review. > > You're right, the GFP_DMA page allocation will fail with a nasty dmesg error if > ZONE_DMA is configured but empty. Unsurprisingly the opposite situation is fine > (GFP_DMA32 with an empty ZONE_DMA32). Was that tested on something other than RPi4 with more than 4GB of RAM? (i.e. with a non-empty ZONE_NORMAL either way) Robin. > I switched to the scheme you're suggesting for the next version of the series. > The comment will be something the likes of this: > > /* > * We create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA's size is decided based > * on whether the SoC's peripherals are able to address the first naturally > * aligned 4 GB of ram. > * > * If limited, ZONE_DMA covers that area and ZONE_DMA32 the rest of that 32 bit > * addressable memory. > * > * If not ZONE_DMA is expanded to cover the whole 32 bit addressable memory and > * ZONE_DMA32 is left empty. > */ > > Regards, > Nicolas > >
On Thu, 2019-08-01 at 17:07 +0100, Robin Murphy wrote: > On 2019-08-01 4:44 pm, Nicolas Saenz Julienne wrote: > > On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote: > > > On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote: > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > > > index 1c4ffabbe1cb..f5279ef85756 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 might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed > > > > if > > > > there > > > > + * are periferals unable to address the first naturally aligned 4GB of > > > > ram. > > > > + * ZONE_DMA32 will be expanded to cover the rest of that memory. If > > > > such > > > > + * limitations doesn't exist only ZONE_DMA32 is created. > > > > + */ > > > > > > Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit > > > range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back > > > onto ZONE_DMA32? > > > > Hi Catalin, thanks for the review. > > > > You're right, the GFP_DMA page allocation will fail with a nasty dmesg error > > if > > ZONE_DMA is configured but empty. Unsurprisingly the opposite situation is > > fine > > (GFP_DMA32 with an empty ZONE_DMA32). > > Was that tested on something other than RPi4 with more than 4GB of RAM? > (i.e. with a non-empty ZONE_NORMAL either way) No, all I did is play around with RPi4's memory size (1 GB vs 4 GB). I'll see If I can get access to a dts based board with more than 4 GB, If not I'll try to fake it. It's not ideal but I can set the limit on 3 GB and have the 3 areas created (with and witouth an empty ZONE_DMA32). On top of that, now that you ask, I realise I neglected all the ACPI based servers. I have access to some so I'll make sure I test everything on them too for the next series. Regards, Nicolas
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3adcec05b1f6..a9fd71d3bc8e 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -266,6 +266,10 @@ config GENERIC_CSUM config GENERIC_CALIBRATE_DELAY def_bool y +config ZONE_DMA + bool "Support DMA zone" if EXPERT + default y + config ZONE_DMA32 bool "Support DMA32 zone" if EXPERT default y diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 1c4ffabbe1cb..f5279ef85756 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 might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed if there + * are periferals unable to address the first naturally aligned 4GB of ram. + * ZONE_DMA32 will be expanded to cover the rest of that memory. If such + * limitations doesn't exist only ZONE_DMA32 is created. + */ +phys_addr_t arm64_dma_phys_limit __ro_after_init; phys_addr_t arm64_dma32_phys_limit __ro_after_init; #ifdef CONFIG_KEXEC_CORE @@ -193,6 +200,9 @@ 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 @@ -207,14 +217,19 @@ 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_dma = PFN_DOWN(arm64_dma_phys_limit); unsigned long max_dma32 = min; memset(zone_size, 0, sizeof(zone_size)); +#ifdef CONFIG_ZONE_DMA + if (max_dma) + zone_size[ZONE_DMA] = max_dma - min; +#endif /* 4GB maximum for 32-bit only capable devices */ #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 - min; #endif zone_size[ZONE_NORMAL] = max - max_dma32; @@ -226,11 +241,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) { @@ -418,6 +439,11 @@ void __init arm64_memblock_init(void) early_init_fdt_scan_reserved_mem(); + if (IS_ENABLED(CONFIG_ZONE_DMA)) + arm64_dma_phys_limit = max_zone_dma_phys(); + else + arm64_dma_phys_limit = 0; + /* 4GB maximum for 32-bit only capable devices */ if (IS_ENABLED(CONFIG_ZONE_DMA32)) arm64_dma32_phys_limit = max_zone_dma32_phys(); @@ -430,7 +456,7 @@ void __init arm64_memblock_init(void) high_memory = __va(memblock_end_of_DRAM() - 1) + 1; - dma_contiguous_reserve(arm64_dma32_phys_limit); + dma_contiguous_reserve(arm64_dma_phys_limit ? : arm64_dma32_phys_limit); } void __init bootmem_init(void) @@ -533,7 +559,7 @@ static void __init free_unused_memmap(void) */ void __init mem_init(void) { - if (swiotlb_force == SWIOTLB_FORCE || + if (swiotlb_force == SWIOTLB_FORCE || arm64_dma_phys_limit || max_pfn > (arm64_dma32_phys_limit >> PAGE_SHIFT)) swiotlb_init(1); else
So far all arm64 devices have supported 32 bit DMA masks for their peripherals. This is not true anymore for the Raspberry Pi 4. Most of it's peripherals can only address the first GB or memory of a total of up to 4 GB. This goes against ZONE_DMA32's original intent, and breaks other subsystems as it's expected for ZONE_DMA32 to be addressable with a 32 bit mask. So it was decided to use ZONE_DMA for this specific case. Devices with with 32 bit DMA addressing support will still bypass ZONE_DMA but those who don't will create both zones. ZONE_DMA will contain the memory addressable by all the SoC's devices and ZONE_DMA32 the rest of the 32 bit addressable memory. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- arch/arm64/Kconfig | 4 ++++ arch/arm64/mm/init.c | 38 ++++++++++++++++++++++++++++++++------ 2 files changed, 36 insertions(+), 6 deletions(-)