On Wed, Dec 09, 2009 at 11:31:24AM +1000, Ben Skeggs wrote:
> On Tue, 2009-12-08 at 15:33 +0100, Jerome Glisse wrote:
> > This change allow driver to pass sorted memory placement,
> > from most prefered placement to least prefered placement.
> > In order to avoid long function prototype a structure is
> > used to gather memory placement informations such as range
> > restriction (if you need a buffer to be in given range).
> > Range restriction is determined by fpfn & lpfn which are
> > the first page and last page number btw which allocation
> > can happen. If those fields are set to 0 ttm will assume
> > buffer can be put anywhere in the address space (thus it
> > avoids putting a burden on the driver to always properly
> > set those fields).
> >
> > This patch also factor few functions like evicting first
> > entry of lru list or getting a memory space. This avoid
> > code duplication.
> >
> > V2: Change API to use placement flags and array instead
> > of packing placement order into a quadword.
> > V3: Make sure we set the appropriate mem.placement flag
> > when validating or allocation memory space.
> A way to pass fpfn/lpfn to ttm_buffer_object_{init,create}() would be
> really useful too. Perhaps passing a struct ttm_placement rather than
> flags to these functions?
>
> Ben.
Unreleased version of the patch did that but i wanted to
minimize the API change. I have no objection against that.
I will do a patch quickly latter today.
Cheers,
Jerome
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
