search for: drm_nouveau_gem_new

This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to specify the tiling options of a PRIME-imported buffer. The staging parameter will allow us

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to

..._TILE_NONCONTIG 0x00000008 +#define NOUVEAU_GEM_EXPLICIT_SYNC 0x00040000 struct drm_nouveau_gem_info { uint32_t handle; @@ -54,7 +55,7 @@ struct drm_nouveau_gem_info { uint64_t offset; uint64_t map_handle; uint32_t tile_mode; - uint32_t tile_flags; + uint32_t bo_flags; }; struct drm_nouveau_gem_new { @@ -149,6 +150,7 @@ struct drm_nouveau_gem_cpu_fini { #define DRM_NOUVEAU_GEM_CPU_FINI 0x43 #define DRM_NOUVEAU_GEM_INFO 0x44 #define DRM_NOUVEAU_GEM_PUSHBUF_2 0x45 +#define DRM_NOUVEAU_GEM_SET_INFO 0x46 #define DRM_IOCTL_NOUVEAU_GEM_NEW DRM_IOWR(DRM_CO...

...DRM_NOUVEAU_GPUOBJ_FREE, &req, sizeof(req)); } } @@ -267,6 +264,7 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment, union nouveau_bo_config *config) { struct nouveau_device *dev = bo->device; + struct nouveau_drm *drm = nouveau_drm(&dev->object); struct drm_nouveau_gem_new req = {}; struct drm_nouveau_gem_info *info = &req.info; int ret; @@ -309,7 +307,7 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment, if (!nouveau_device(dev)->have_bo_usage) info->tile_flags &= 0x0000ff00; - ret = drmCommandWriteRead(dev->fd, DRM_NOUVEAU_GEM_NE...

...node = node; > mem->start = 0; > diff --git a/drm/nouveau/uapi/drm/nouveau_drm.h b/drm/nouveau/uapi/drm/nouveau_drm.h > index 4e7e21f41b5c..8f10b16b1473 100644 > --- a/drm/nouveau/uapi/drm/nouveau_drm.h > +++ b/drm/nouveau/uapi/drm/nouveau_drm.h > @@ -64,6 +64,12 @@ struct drm_nouveau_gem_new { > uint32_t align; > }; > > +struct drm_nouveau_gem_set_tiling { > + uint32_t handle; > + uint32_t tile_mode; > + uint32_t tile_flags; > +}; > + > #define NOUVEAU_GEM_MAX_BUFFERS 1024 > struct drm_nouveau_gem_pushbuf_bo_presumed { > uint32_t valid; &...

I am trying to figure out why the ttm_bo_vm_fault is stitching pages from the GART instead of the pages allocated via DRM_NOUVEAU_GEM_NEW. And also why OUR_RINGp is writing 16, 256 and 512 bytes of zero filled data *1 in the GART? Perhaps I should mention that I know _why_ it is taking the pages from the GART and giving them to the userland - but I don't know if that is correct way of doing it. Let me explain the steps to lead t...

...EM_CPU_FINI 0x43 > #define DRM_NOUVEAU_GEM_INFO 0x44 > +/* range 0x98..DRM_COMMAND_END (8 entries) is reserved for staging, unstable ioctls */ > +#define DRM_NOUVEAU_STAGING_IOCTL 0x58 > > #define DRM_IOCTL_NOUVEAU_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_NEW, struct drm_nouveau_gem_new) > #define DRM_IOCTL_NOUVEAU_GEM_PUSHBUF DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_PUSHBUF, struct drm_nouveau_gem_pushbuf) > #define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP DRM_IOW (DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_pr...

..._node = node; > mem->start = 0; > diff --git a/drm/nouveau/uapi/drm/nouveau_drm.h b/drm/nouveau/uapi/drm/nouveau_drm.h > index 4e7e21f41b5c..8f10b16b1473 100644 > --- a/drm/nouveau/uapi/drm/nouveau_drm.h > +++ b/drm/nouveau/uapi/drm/nouveau_drm.h > @@ -64,6 +64,12 @@ struct drm_nouveau_gem_new { > uint32_t align; > }; > > +struct drm_nouveau_gem_set_tiling { > + uint32_t handle; > + uint32_t tile_mode; > + uint32_t tile_flags; > +}; > + > #define NOUVEAU_GEM_MAX_BUFFERS 1024 > struct drm_nouveau_gem_pushbuf_bo_presumed { > uint32_t valid; >...

From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the

...0x07 >> #define DRM_NOUVEAU_SVM_INIT 0x08 >> #define DRM_NOUVEAU_SVM_BIND 0x09 >> +#define DRM_NOUVEAU_VM_INIT 0x10 >> +#define DRM_NOUVEAU_VM_BIND 0x11 >> +#define DRM_NOUVEAU_EXEC 0x12 >> #define DRM_NOUVEAU_GEM_NEW 0x40 >> #define DRM_NOUVEAU_GEM_PUSHBUF 0x41 >> #define DRM_NOUVEAU_GEM_CPU_PREP 0x42 >> @@ -197,6 +410,9 @@ struct drm_nouveau_svm_bind { >> #define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI DRM_IOW (DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_CPU_FINI, stru...

...#define DRM_NOUVEAU_SVM_INIT?????????? 0x08 >>> ? #define DRM_NOUVEAU_SVM_BIND?????????? 0x09 >>> +#define DRM_NOUVEAU_VM_INIT??????????? 0x10 >>> +#define DRM_NOUVEAU_VM_BIND??????????? 0x11 >>> +#define DRM_NOUVEAU_EXEC?????????????? 0x12 >>> ? #define DRM_NOUVEAU_GEM_NEW??????????? 0x40 >>> ? #define DRM_NOUVEAU_GEM_PUSHBUF??????? 0x41 >>> ? #define DRM_NOUVEAU_GEM_CPU_PREP?????? 0x42 >>> @@ -197,6 +410,9 @@ struct drm_nouveau_svm_bind { >>> ? #define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI?????? DRM_IOW >>> (DRM_COMMAND_BASE +...

...? ?0x07 > ?#define DRM_NOUVEAU_SVM_INIT? ? ? ? ? ?0x08 > ?#define DRM_NOUVEAU_SVM_BIND? ? ? ? ? ?0x09 > +#define DRM_NOUVEAU_VM_INIT? ? ? ? ? ? 0x10 > +#define DRM_NOUVEAU_VM_BIND? ? ? ? ? ? 0x11 > +#define DRM_NOUVEAU_EXEC? ? ? ? ? ? ? ?0x12 > ?#define DRM_NOUVEAU_GEM_NEW? ? ? ? ? ? 0x40 > ?#define DRM_NOUVEAU_GEM_PUSHBUF? ? ? ? 0x41 > ?#define DRM_NOUVEAU_GEM_CPU_PREP? ? ? ?0x42 > @@ -197,6 +403,9 @@ struct drm_nouveau_svm_bind { > ?#define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI? ? ? ?DRM_IOW > (DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_CPU_F...

...f -Naur a/drivers/gpu/drm/nouveau/nouveau_channel.c b/drivers/gpu/drm/nouveau/nouveau_channel.c --- a/drivers/gpu/drm/nouveau/nouveau_channel.c 2010-01-18 13:27:35.702877591 +0100 +++ b/drivers/gpu/drm/nouveau/nouveau_channel.c 2010-01-18 13:30:35.002877939 +0100 @@ -420,8 +420,6 @@ DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, DRM_AUTH), DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, DRM_AUTH), DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_PUSHBUF_CALL, nouveau_gem_ioctl_pushbuf_call, DRM_AUTH), - DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_PIN, nouveau_gem_ioctl_pin, DRM_AUTH), - DRM_IOCTL_DEF(DRM_NOUVE...

...M_INIT 0x08 >>>> #define DRM_NOUVEAU_SVM_BIND 0x09 >>>> +#define DRM_NOUVEAU_VM_INIT 0x10 >>>> +#define DRM_NOUVEAU_VM_BIND 0x11 >>>> +#define DRM_NOUVEAU_EXEC 0x12 >>>> #define DRM_NOUVEAU_GEM_NEW 0x40 >>>> #define DRM_NOUVEAU_GEM_PUSHBUF 0x41 >>>> #define DRM_NOUVEAU_GEM_CPU_PREP 0x42 >>>> @@ -197,6 +410,9 @@ struct drm_nouveau_svm_bind { >>>> #define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI DRM_IOW (DRM_COMMAND_BA...

...--- a/include/drm/nouveau_drm.h +++ b/include/drm/nouveau_drm.h @@ -200,6 +200,7 @@ struct drm_nouveau_sarea { #define DRM_NOUVEAU_GROBJ_ALLOC 0x04 #define DRM_NOUVEAU_NOTIFIEROBJ_ALLOC 0x05 #define DRM_NOUVEAU_GPUOBJ_FREE 0x06 +#define DRM_NOUVEAU_NVIF 0x07 #define DRM_NOUVEAU_GEM_NEW 0x40 #define DRM_NOUVEAU_GEM_PUSHBUF 0x41 #define DRM_NOUVEAU_GEM_CPU_PREP 0x42 diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am index 25ea6dc..76cdeca 100644 --- a/nouveau/Makefile.am +++ b/nouveau/Makefile.am @@ -14,9 +14,18 @@ libdrm_nouveau_la_LIBADD = ../libdrm....

...--- a/include/drm/nouveau_drm.h +++ b/include/drm/nouveau_drm.h @@ -200,6 +200,7 @@ struct drm_nouveau_sarea { #define DRM_NOUVEAU_GROBJ_ALLOC 0x04 #define DRM_NOUVEAU_NOTIFIEROBJ_ALLOC 0x05 #define DRM_NOUVEAU_GPUOBJ_FREE 0x06 +#define DRM_NOUVEAU_NVIF 0x07 #define DRM_NOUVEAU_GEM_NEW 0x40 #define DRM_NOUVEAU_GEM_PUSHBUF 0x41 #define DRM_NOUVEAU_GEM_CPU_PREP 0x42 diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am index 25ea6dc..76cdeca 100644 --- a/nouveau/Makefile.am +++ b/nouveau/Makefile.am @@ -14,9 +14,18 @@ libdrm_nouveau_la_LIBADD = ../libdrm....

...--- a/include/drm/nouveau_drm.h +++ b/include/drm/nouveau_drm.h @@ -200,6 +200,7 @@ struct drm_nouveau_sarea { #define DRM_NOUVEAU_GROBJ_ALLOC 0x04 #define DRM_NOUVEAU_NOTIFIEROBJ_ALLOC 0x05 #define DRM_NOUVEAU_GPUOBJ_FREE 0x06 +#define DRM_NOUVEAU_NVIF 0x07 #define DRM_NOUVEAU_GEM_NEW 0x40 #define DRM_NOUVEAU_GEM_PUSHBUF 0x41 #define DRM_NOUVEAU_GEM_CPU_PREP 0x42 diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am index 25ea6dc..76cdeca 100644 --- a/nouveau/Makefile.am +++ b/nouveau/Makefile.am @@ -14,9 +14,18 @@ libdrm_nouveau_la_LIBADD = ../libdrm....

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- nouveau/abi16.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++----- nouveau/nouveau.c | 56 +++++++------------------------------------------ nouveau/private.h | 7 ++----- 3 files changed, 67 insertions(+), 58 deletions(-) diff --git a/nouveau/abi16.c b/nouveau/abi16.c index

https://bugs.freedesktop.org/show_bug.cgi?id=47556 Bug #: 47556 Summary: nouveau driver can`t handle xrandr requests Classification: Unclassified Product: xorg Version: 7.6 (2010.12) Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau