On Sun, 2019-09-08 at 22:27 +0100, Catalin Marinas wrote:
> On Fri, Sep 06, 2019 at 02:06:14PM +0200, Nicolas Saenz Julienne wrote:
> > @@ -430,7 +454,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)
> > @@ -534,6 +558,7 @@ static void __init free_unused_memmap(void)
> >  void __init mem_init(void)
> >  {
> >     if (swiotlb_force == SWIOTLB_FORCE ||
> > +       max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT) ||
> >         max_pfn > (arm64_dma32_phys_limit >> PAGE_SHIFT))
> >             swiotlb_init(1);
> 
> So here we want to initialise the swiotlb only if we need bounce
> buffers. Prior to this patch, we assumed that swiotlb is needed if
> max_pfn is beyond the reach of 32-bit devices. With ZONE_DMA, we need to
> lower this limit to arm64_dma_phys_limit.
>
> If ZONE_DMA is enabled, just comparing max_pfn with arm64_dma_phys_limit
> is sufficient since the dma32 one limit always higher. However, if
> ZONE_DMA is disabled, arm64_dma_phys_limit is 0, so we may initialise
> swiotlb unnecessarily. I guess you need a similar check to the
> dma_contiguous_reserve() above.

Of course.

> 
> With that:
> 
> Reviewed-by: Catalin Marinas <[email protected]>
> 
> Unless there are other objections, I can queue this series for 5.5 in a
> few weeks time (too late for 5.4).

Thanks!

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to