[RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation

[Sin, David]

Russell, 

> -----Original Message-----
> From: Sin, David 
> Sent: Monday, August 02, 2010 9:55 AM
> To: Shilimkar, Santosh; Russell King - ARM Linux; Woodruff, Richard
> Cc: linux-omap at vger.kernel.org; Tony Lindgren; Kanigeri, 
> Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Molnar, Lajos; 
> Voultoury, Pierre; linux-arm-kernel at lists.infradead.org
> Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager 
> interface and implementation
> 
> -----Original Message-----
> From: Shilimkar, Santosh 
> Sent: Monday, August 02, 2010 9:53 AM
> To: Sin, David; Russell King - ARM Linux; Woodruff, Richard
> Cc: linux-omap at vger.kernel.org; Tony Lindgren; Kanigeri, 
> Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Molnar, Lajos; 
> Voultoury, Pierre; linux-arm-kernel at lists.infradead.org
> Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager 
> interface and implementation
> 
> 
> 
> > -----Original Message-----
> > From: Sin, David
> > Sent: Monday, August 02, 2010 8:20 PM
> > To: Shilimkar, Santosh; Russell King - ARM Linux; Woodruff, Richard
> > Cc: linux-omap at vger.kernel.org; Tony Lindgren; Kanigeri, 
> Hari; Ohad Ben-
> > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; 
> linux-arm-
> > kernel at lists.infradead.org
> > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
> > implementation
> > 
> > -----Original Message-----
> > From: Shilimkar, Santosh
> > Sent: Monday, August 02, 2010 9:45 AM
> > To: Sin, David; Russell King - ARM Linux; Woodruff, Richard
> > Cc: linux-omap at vger.kernel.org; Tony Lindgren; Kanigeri, 
> Hari; Ohad Ben-
> > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; 
> linux-arm-
> > kernel at lists.infradead.org
> > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
> > implementation
> > 
> < snip>
> 
> > > > +	m->pa = page_to_phys(m->pg);
> > > > +
> > > > +	/* flush the cache entry for each page we allocate. */
> > > > +	dmac_flush_range(page_address(m->pg),
> > > > +				page_address(m->pg) + 
> PAGE_SIZE);
> > > > +	outer_flush_range(m->pa, m->pa + PAGE_SIZE);
> > >
> > > NAK.  This is an abuse of these interfaces, and is buggy 
> in any case.
> > >
> > > ARMv6 and ARMv7 CPUs speculatively prefetch memory, which 
> means that
> > > there's no guarantee that if you flush the caches for a particular
> > > range of virtual space, that it will stay flushed until you decide
> > > to read it.  So flushing the caches in some memory allocator can't
> > > guarantee that when you eventually get around to using 
> the page that
> > > there won't be cache lines associated with it.
> > >
> > > [dhs] Russell, thanks for reviewing this code.  Do you have any
> > interface
> > > suggestions that you can share that would make this 
> proper?  Ideally, I
> > > would like to get physical pages without associated 
> virtual address, or
> > > ones that are non-cached/non-bufferable.
> > 
> > There is nothing called 'non-bufferable' any more David on ARMv6 and
> > ARMv7.
> > You can get non-cached memory using "dma_alloc_coherent"
> > 
> > [dhs] Thanks, Santosh, for the clarification.  I believe
> > dma_alloc_coherent is quite limited, right?  We need to be 
> able to cover
> > potentially 128MB of physical memory for the TILER.  BTW, 
> does GFP_DMA
> > indicate that I don't want cached memory?
> > 
> It's configurable. By default it's 2 MB pool. GFP_DMA doesn't give you
> un-cacheable memory.
> 
> [dhs] OK -- I will increase this and try to allocate this 
> way.  Thank you.
> 
> 

As Santosh suggests, I will increase the dma_alloc_coherent pool size to something that will accomdate TILER requirements.  I believe this will work, as I'm only making 4k allocations per call, as opposed to one large contiguous allocation.  However, I'd like to be able to use an API similar to alloc_page() that gives back device or strongly ordered memory so that we don't have to pre-allocate such a large amount at boot-up.  Is this something that you're considering on your end for the near future?  Thanks for working through this with us.

Regards,
-David