Fwd: [RFC] TTM user interface.

[Austin Y. <yua...@gm...>]

On Mon, Sep 15, 2008 at 9:24 PM, Thomas Hellström
<th...@tu...> wrote:
> No. In fact there is no big change in usage pattern. Map / RW / Unmap is
> there, except
> it works without syncing. So to mimic the old behaviour you'd do
>
> map()
> sync_for_cpu()
> RW
> release_from_cpu()
> unmap()
TTM_BO_SYNCCPU is used for sync_for_cpu/release_from_cpu, right?

> No, it will not. Note that this user interface suggestion is not set in
> stone for each driver that
> uses the TTM functionality, but the user interface TG will most probably use
> for drivers not
> deriving from GEM objects. The Radeon driver takes another approach and
> derives BOs from
> GEM objects and TTM BOs. In that case, the above user interface does not
> apply.
>
> It's possible to create a shmem object without any pages backing it, if
> needed.
>
> For user-buffers one should probably construct a separate driver-specific
> IOCTL.
> Since this is an RFC, and I agree that user-buffers are sometimes very handy
> I'll include
> a user-buffer create IOCTL and send out a new version.
Do you mean you will create a new IOCTL for user buffers? I originally
wondered how to wrap my special BO creation request (BO pages are from
a camera) into current TTM_BO_CREATE IOCTL following your proposal and
not using GEM objects. If it also needs a new IOCTL, there will be 3
IOCTLs for BO creation?
In general, for my BO_create_from_camera_pages IOCTL, except
size/placement(will be TT)/page_alignment, I need an extra private
date which indicates a ID of camera pages. I like a "uint64_t
priv_date" inserted into ttm_bo_create_req although it looks odd..

Just some thoughts

Thanks
Austin

p.s. :
struct ttm_bo_create_req {
       uint64_t size;
       uint32_t placement;
       uint32_t page_alignment;
};
vs.
struct drm_bo_create_req {
       uint64_t mask;
       uint64_t size;
       uint64_t buffer_start;
       unsigned int hint;
       unsigned int page_alignment;
};