[v4,0/7] arm64: Default to 32-bit wide ZONE_DMA
mbox series

Message ID 20201021123437.21538-1-nsaenzjulienne@suse.de
Headers show
Series
  • arm64: Default to 32-bit wide ZONE_DMA
Related show

Message

Nicolas Saenz Julienne Oct. 21, 2020, 12:34 p.m. UTC
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.

---

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(-)

Comments

Jeremy Linton Oct. 23, 2020, 7:05 p.m. UTC | #1
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(-)
>
Nicolas Saenz Julienne Oct. 27, 2020, 11:50 a.m. UTC | #2
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!