Re: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations

[Scott Wood <oss@buserror.net>]

On Mon, 2017-04-03 at 15:52 +0100, Robin Murphy wrote:
> On 01/04/17 08:25, Scott Wood wrote:
> > 
> > On Fri, 2017-03-31 at 18:55 +0100, Robin Murphy wrote:
> > > 
> > > On 31/03/17 04:27, Michael Ellerman wrote:
> > > > 
> > > > 
> > > > Robin Murphy <robin.murphy@arm.com> writes:
> > > > 
> > > > > 
> > > > > 
> > > > > Hi Roy,
> > > > > 
> > > > > On 29/03/17 22:13, Roy Pledge wrote:
> > > > > > 
> > > > > > 
> > > > > > Use the shared-memory-pool mechanism for frame queue descriptor
> > > > > > and
> > > > > > packed frame descriptor record area allocations.
> > > > > Thanks for persevering with this - in my opinion it's now looking
> > > > > like
> > > > > it was worth the effort :)
> > > > > 
> > > > > AFAICS the ioremap_wc() that this leads to does appear to give back
> > > > > something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't
> > > > > horrendously misnamed), and "no-map" should rule out any cacheable
> > > > > linear map alias existing, so it would seem that this approach
> > > > > should
> > > > > avert Scott's concerns about attribute mismatches.
> > > > How does 'no-map' translate into something being excluded from the
> > > > linear mapping?
> > > Reserved regions marked with "no-map" get memblock_remove()d by
> > > early_init_dt_alloc_reserved_memory_arch(). As I understand things, the
> > > linear map should only cover memblock areas, and it would be explicitly
> > > violating the semantics of "no-map" to still cover such a region.
> > Discontiguous memory isn't supported on these PPC chips.  Everything up to
> > memblock_end_of_DRAM() gets mapped -- and if that were to change, the
> > fragmentation would waste TLB1 entries.
> Ah, so the "PPC-specific angles I'm not aware of" category is indeed
> non-empty - I guess the lack of HAVE_GENERIC_DMA_COHERENT might be
> related, then.
> 
> That said, though, AFAICS only certain x86 and s390 configurations ever
> call memblock_set_bottom_up(true), so we should be able to assume that
> the reserved region allocations always fall through to
> __memblock_find_range_top_down(). Thus if your DRAM is contiguous, then
> "no-map"-ing the reserved regions will simply end up pushing
> memblock_end_of_DRAM() down in a manner that would appear to still avoid
> overlaps.

Can you guarantee it will be at the end?  What if there were other early
memblock allocations (e.g. other reserved-memory regions without no-map) that
came first?

>  I can only see that going wrong if the end of DRAM wasn't at
> least 32MB aligned to begin with - is that ever likely to happen in
> practice?

Probably not, unless the user asks for an unusual memory size via mem= or
similar.

-Scott