Message ID | 20201021123437.21538-1-nsaenzjulienne@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | arm64: Default to 32-bit wide ZONE_DMA | expand |
Hi, On 10/21/20 7:34 AM, Nicolas Saenz Julienne wrote: > Using two distinct DMA zones turned out to be problematic. Here's an > attempt go back to a saner default. > > I tested this on both a RPi4 and QEMU. I've tested this in ACPI mode on the rpi4 (4+8G with/without the 3G limiter) as well, with Ard's IORT patch. Nothing seems to have regressed. Thanks, Tested-by: Jeremy Linton <jeremy.linton@arm.com> > > --- > > Changes since v3: > - Drop patch adding define in dma-mapping > - Address small review changes > - Update Ard's patch > - Add new patch removing examples from mmzone.h > > Changes since v2: > - Introduce Ard's patch > - Improve OF dma-ranges parsing function > - Add unit test for OF function > - Address small changes > - Move crashkernel reservation later in boot process > > Changes since v1: > - Parse dma-ranges instead of using machine compatible string > > Ard Biesheuvel (1): > arm64: mm: Set ZONE_DMA size based on early IORT scan > > Nicolas Saenz Julienne (6): > arm64: mm: Move reserve_crashkernel() into mem_init() > arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() > of/address: Introduce of_dma_get_max_cpu_address() > of: unittest: Add test for of_dma_get_max_cpu_address() > arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges > mm: Remove examples from enum zone_type comment > > arch/arm64/mm/init.c | 16 ++++++------ > drivers/acpi/arm64/iort.c | 52 +++++++++++++++++++++++++++++++++++++++ > drivers/of/address.c | 42 +++++++++++++++++++++++++++++++ > drivers/of/unittest.c | 18 ++++++++++++++ > include/linux/acpi_iort.h | 4 +++ > include/linux/mmzone.h | 20 --------------- > include/linux/of.h | 7 ++++++ > 7 files changed, 130 insertions(+), 29 deletions(-) >
On Fri, 2020-10-23 at 14:05 -0500, Jeremy Linton wrote: > Hi, > > On 10/21/20 7:34 AM, Nicolas Saenz Julienne wrote: > > Using two distinct DMA zones turned out to be problematic. Here's an > > attempt go back to a saner default. > > > > I tested this on both a RPi4 and QEMU. > > I've tested this in ACPI mode on the rpi4 (4+8G with/without the 3G > limiter) as well, with Ard's IORT patch. Nothing seems to have regressed. > > Thanks, > > Tested-by: Jeremy Linton <jeremy.linton@arm.com> Thanks!