On Sat, 2015-02-21 at 19:26 +0800, Kevin Hao wrote:
> On Fri, Feb 20, 2015 at 07:35:25PM +1100, Benjamin Herrenschmidt wrote:
> > We do this for consistency and also in order to support the use of a
> > consistent mask smaller than the dma mask in subsequent patches.
> > 
> > Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> > ---
> >  arch/powerpc/kernel/dma-swiotlb.c | 3 ---
> >  arch/powerpc/mm/mem.c             | 6 ++++++
> >  2 files changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/powerpc/kernel/dma-swiotlb.c 
> > b/arch/powerpc/kernel/dma-swiotlb.c
> > index 7359797..cb92f94 100644
> > --- a/arch/powerpc/kernel/dma-swiotlb.c
> > +++ b/arch/powerpc/kernel/dma-swiotlb.c
> > @@ -110,9 +110,6 @@ void __init swiotlb_detect_4g(void)
> >  {
> >     if ((memblock_end_of_DRAM() - 1) > 0xffffffff) {
> >             ppc_swiotlb_enable = 1;
> > -#ifdef CONFIG_ZONE_DMA32
> > -           limit_zone_pfn(ZONE_DMA32, (1ULL << 32) >> PAGE_SHIFT);
> > -#endif
> >     }
> >  }
> >  
> > diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> > index b7285a5..f146ef0 100644
> > --- a/arch/powerpc/mm/mem.c
> > +++ b/arch/powerpc/mm/mem.c
> > @@ -307,6 +307,12 @@ void __init paging_init(void)
> >     printk(KERN_DEBUG "Memory hole size: %ldMB\n",
> >            (long int)((top_of_ram - total_ram) >> 20));
> >  
> > +#ifdef CONFIG_ZONE_DMA32
> > +   /* Default limit for ZONE_DMA32, platform might limit it
> > +    * further due to PCI bridge addressing limitations
> > +    */
> > +   limit_zone_pfn(ZONE_DMA32, (1ULL << 32) >> PAGE_SHIFT);
> > +#endif
> >  #ifdef CONFIG_HIGHMEM
> 
> Hmm, won't this break the PCI on the fsl SoCs? The ZONE_DMA32 is set to
> 2GB due to the PCI inbound window limitation on fsl SoCs. This will override
> that unconditionally. Please see the commit 84f44cc56c09 ("powerpc/fsl-pci:
> Limit ZONE_DMA32 to 2GiB on 64-bit platforms") for more detail.

No it won't, or am I missing something ? Ie, limit_zone_pfn() will only
reduce the size of the window, never increase it.

Cheers,
Ben.

> Thanks,
> Kevin


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to