[Nouveau] [PATCH v2 6/7] drm/exec: Pass in initial # of objects
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c | 4 ++--
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
drivers/gpu/drm/drm_exec.c | 13 ++---
drivers/gpu/drm/nouveau/nouveau_exec.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +-
drivers/gpu/drm/tests/drm_exec_test.c| 16
include/drm/drm_exec.h | 2 +-
12 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 41fbc4fd0fac..0bd3c4a6267a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1137,7 +1137,7 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
ctx->n_vms = 1;
ctx->sync = &mem->sync;
- drm_exec_init(&ctx->exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ drm_exec_init(&ctx->exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
drm_exec_until_all_locked(&ctx->exec) {
ret = amdgpu_vm_lock_pd(vm, &ctx->exec, 2);
drm_exec_retry_on_contention(&ctx->exec);
@@ -1176,7 +1176,7 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
int ret;
ctx->sync = &mem->sync;
- drm_exec_init(&ctx->exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ drm_exec_init(&ctx->exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
drm_exec_until_all_locked(&ctx->exec) {
ctx->n_vms = 0;
list_for_each_entry(entry, &mem->attachments, list) {
@@ -2552,7 +2552,7 @@ static int validate_invalid_user_pages(struct
amdkfd_process_info *process_info)
amdgpu_sync_create(&sync);
- drm_exec_init(&exec, 0);
+ drm_exec_init(&exec, 0, 0);
/* Reserve all BOs and page tables for validation */
drm_exec_until_all_locked(&exec) {
/* Reserve all the page directories */
@@ -2793,7 +2793,7 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
mutex_lock(&process_info->lock);
- drm_exec_init(&exec, 0);
+ drm_exec_init(&exec, 0, 0);
drm_exec_until_all_locked(&exec) {
list_for_each_entry(peer_vm, &process_info->vm_list_head,
vm_list_node) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index df3ecfa9e13f..2464606494d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -66,7 +66,7 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p,
amdgpu_sync_create(&p->sync);
drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
- DRM_EXEC_IGNORE_DUPLICATES);
+ DRM_EXEC_IGNORE_DUPLICATES, 0);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 720011019741..796fa6f1420b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -70,7 +70,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
struct drm_exec exec;
int r;
- drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
drm_exec_until_all_locked(&exec) {
r = amdgpu_vm_lock_pd(vm, &exec, 0);
if (likely(!r))
@@ -110,7 +110,7 @@ int amdgpu_unmap_static_csa(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
struct drm_exec exec;
int r;
- drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
drm_exec_until_all_locked(&exec) {
r = amdgpu_vm_lock_pd(vm, &exec, 0);
if (likely(!r))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 84beeaa4d21c..49a5f1c73b3e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -203,7 +203,7 @@ static void amdgpu_gem_object_close(struct drm_gem_object
*obj,
struct drm_exec exec;
long r;
- drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES);
+ drm_exec_init(&exec, D
[Nouveau] [PATCH v2 0/7] drm/msm/gem: drm_exec conversion
From: Rob Clark Simplify the exec path (removing a legacy optimization) and convert to drm_exec. One drm_exec patch to allow passing in the expected # of GEM objects to avoid re-allocation. I'd be a bit happier if I could avoid the extra objects table allocation in drm_exec in the first place, but wasn't really happy with any of the things I tried to get rid of that. v2: updates in 6/7 and other nit-addressing Rob Clark (7): drm/msm/gem: Remove "valid" tracking drm/msm/gem: Remove submit_unlock_unpin_bo() drm/msm/gem: Don't queue job to sched in error cases drm/msm/gem: Split out submit_unpin_objects() helper drm/msm/gem: Cleanup submit_cleanup_bo() drm/exec: Pass in initial # of objects drm/msm/gem: Convert to drm_exec .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +- drivers/gpu/drm/drm_exec.c| 13 +- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/msm_gem.h | 13 +- drivers/gpu/drm/msm/msm_gem_submit.c | 199 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +- drivers/gpu/drm/nouveau/nouveau_exec.c| 2 +- drivers/gpu/drm/nouveau/nouveau_uvmm.c| 2 +- drivers/gpu/drm/tests/drm_exec_test.c | 16 +- include/drm/drm_exec.h| 2 +- 16 files changed, 92 insertions(+), 187 deletions(-) -- 2.42.0
Re: [Nouveau] [PATCH 6/7] drm/exec: Pass in initial # of objects
On Mon, Oct 30, 2023 at 9:01 AM Christian König
wrote:
>
> Am 30.10.23 um 14:38 schrieb Rob Clark:
> > On Mon, Oct 30, 2023 at 1:05 AM Christian König
> > wrote:
> >> Am 27.10.23 um 18:58 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
> >>> In cases where the # is known ahead of time, it is silly to do the table
> >>> resize dance.
> >> Ah, yes that was my initial implementation as well, but I ditched that
> >> because nobody actually used it.
> >>
> >> One comment below.
> >>
> >>> Signed-off-by: Rob Clark
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++--
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 ++--
> >>>drivers/gpu/drm/drm_exec.c | 15 ---
> >>>drivers/gpu/drm/nouveau/nouveau_exec.c | 2 +-
> >>>drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +-
> >>>include/drm/drm_exec.h | 2 +-
> >>>8 files changed, 22 insertions(+), 13 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> index efdb1c48f431..d27ca8f61929 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >>> @@ -65,7 +65,7 @@ static int amdgpu_cs_parser_init(struct
> >>> amdgpu_cs_parser *p,
> >>>}
> >>>
> >>>amdgpu_sync_create(&p->sync);
> >>> - drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
> >>> + drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
> >>>return 0;
> >>>}
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> >>> index 720011019741..796fa6f1420b 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> >>> @@ -70,7 +70,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev,
> >>> struct amdgpu_vm *vm,
> >>>struct drm_exec exec;
> >>>int r;
> >>>
> >>> - drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
> >>> + drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
> >>>drm_exec_until_all_locked(&exec) {
> >>>r = amdgpu_vm_lock_pd(vm, &exec, 0);
> >>>if (likely(!r))
> >>> @@ -110,7 +110,7 @@ int amdgpu_unmap_static_csa(struct amdgpu_device
> >>> *adev, struct amdgpu_vm *vm,
> >>>struct drm_exec exec;
> >>>int r;
> >>>
> >>> - drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
> >>> + drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
> >>>drm_exec_until_all_locked(&exec) {
> >>>r = amdgpu_vm_lock_pd(vm, &exec, 0);
> >>>if (likely(!r))
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> index ca4d2d430e28..16f1715148ad 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> @@ -203,7 +203,7 @@ static void amdgpu_gem_object_close(struct
> >>> drm_gem_object *obj,
> >>>struct drm_exec exec;
> >>>long r;
> >>>
> >>> - drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES);
> >>> + drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES, 0);
> >>>drm_exec_until_all_locked(&exec) {
> >>>r = drm_exec_prepare_obj(&exec, &bo->tbo.base, 1);
> >>>drm_exec_retry_on_contention(&exec);
> >>> @@ -739,7 +739,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
> >>> *data,
> >>>}
> >>>
> >>>drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
> >>> - DRM_EXEC_IGNORE_DUPLICATES);
> >>> + DRM_EXEC_IGNORE_DUPLICATES, 0);
> >>>drm_exec_until_all_lock
Re: [Nouveau] [PATCH 6/7] drm/exec: Pass in initial # of objects
On Mon, Oct 30, 2023 at 1:05 AM Christian König
wrote:
>
> Am 27.10.23 um 18:58 schrieb Rob Clark:
> > From: Rob Clark
> >
> > In cases where the # is known ahead of time, it is silly to do the table
> > resize dance.
>
> Ah, yes that was my initial implementation as well, but I ditched that
> because nobody actually used it.
>
> One comment below.
>
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++--
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
> > drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 ++--
> > drivers/gpu/drm/drm_exec.c | 15 ---
> > drivers/gpu/drm/nouveau/nouveau_exec.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +-
> > include/drm/drm_exec.h | 2 +-
> > 8 files changed, 22 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index efdb1c48f431..d27ca8f61929 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -65,7 +65,7 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser
> > *p,
> > }
> >
> > amdgpu_sync_create(&p->sync);
> > - drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
> > + drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > index 720011019741..796fa6f1420b 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > @@ -70,7 +70,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev,
> > struct amdgpu_vm *vm,
> > struct drm_exec exec;
> > int r;
> >
> > - drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
> > + drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
> > drm_exec_until_all_locked(&exec) {
> > r = amdgpu_vm_lock_pd(vm, &exec, 0);
> > if (likely(!r))
> > @@ -110,7 +110,7 @@ int amdgpu_unmap_static_csa(struct amdgpu_device *adev,
> > struct amdgpu_vm *vm,
> > struct drm_exec exec;
> > int r;
> >
> > - drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
> > + drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
> > drm_exec_until_all_locked(&exec) {
> > r = amdgpu_vm_lock_pd(vm, &exec, 0);
> > if (likely(!r))
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > index ca4d2d430e28..16f1715148ad 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > @@ -203,7 +203,7 @@ static void amdgpu_gem_object_close(struct
> > drm_gem_object *obj,
> > struct drm_exec exec;
> > long r;
> >
> > - drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES);
> > + drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES, 0);
> > drm_exec_until_all_locked(&exec) {
> > r = drm_exec_prepare_obj(&exec, &bo->tbo.base, 1);
> > drm_exec_retry_on_contention(&exec);
> > @@ -739,7 +739,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
> > *data,
> > }
> >
> > drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
> > - DRM_EXEC_IGNORE_DUPLICATES);
> > + DRM_EXEC_IGNORE_DUPLICATES, 0);
> > drm_exec_until_all_locked(&exec) {
> > if (gobj) {
> > r = drm_exec_lock_obj(&exec, gobj);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > index b6015157763a..3c351941701e 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > @@ -1105,7 +1105,7 @@ int amdgpu_mes_ctx_map_meta_data(struct amdgpu_device
> > *adev,
> >
> > amdgpu_sync_create(&sync);
> >
> > - drm_exec_init(&exec, 0);
> > + drm_exec_init(&exec, 0, 0);
> > drm_exec_until_all_locked(&exec) {
> > r = drm_exec_lock_obj(&exec,
> > &ctx_data->meta_data_obj->tbo.base);
[Nouveau] [PATCH 6/7] drm/exec: Pass in initial # of objects
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 ++--
drivers/gpu/drm/drm_exec.c | 15 ---
drivers/gpu/drm/nouveau/nouveau_exec.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +-
include/drm/drm_exec.h | 2 +-
8 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index efdb1c48f431..d27ca8f61929 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -65,7 +65,7 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p,
}
amdgpu_sync_create(&p->sync);
- drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 720011019741..796fa6f1420b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -70,7 +70,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
struct drm_exec exec;
int r;
- drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
drm_exec_until_all_locked(&exec) {
r = amdgpu_vm_lock_pd(vm, &exec, 0);
if (likely(!r))
@@ -110,7 +110,7 @@ int amdgpu_unmap_static_csa(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
struct drm_exec exec;
int r;
- drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
drm_exec_until_all_locked(&exec) {
r = amdgpu_vm_lock_pd(vm, &exec, 0);
if (likely(!r))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index ca4d2d430e28..16f1715148ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -203,7 +203,7 @@ static void amdgpu_gem_object_close(struct drm_gem_object
*obj,
struct drm_exec exec;
long r;
- drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES);
+ drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES, 0);
drm_exec_until_all_locked(&exec) {
r = drm_exec_prepare_obj(&exec, &bo->tbo.base, 1);
drm_exec_retry_on_contention(&exec);
@@ -739,7 +739,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
}
drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
- DRM_EXEC_IGNORE_DUPLICATES);
+ DRM_EXEC_IGNORE_DUPLICATES, 0);
drm_exec_until_all_locked(&exec) {
if (gobj) {
r = drm_exec_lock_obj(&exec, gobj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
index b6015157763a..3c351941701e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
@@ -1105,7 +1105,7 @@ int amdgpu_mes_ctx_map_meta_data(struct amdgpu_device
*adev,
amdgpu_sync_create(&sync);
- drm_exec_init(&exec, 0);
+ drm_exec_init(&exec, 0, 0);
drm_exec_until_all_locked(&exec) {
r = drm_exec_lock_obj(&exec,
&ctx_data->meta_data_obj->tbo.base);
@@ -1176,7 +1176,7 @@ int amdgpu_mes_ctx_unmap_meta_data(struct amdgpu_device
*adev,
struct drm_exec exec;
long r;
- drm_exec_init(&exec, 0);
+ drm_exec_init(&exec, 0, 0);
drm_exec_until_all_locked(&exec) {
r = drm_exec_lock_obj(&exec,
&ctx_data->meta_data_obj->tbo.base);
diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
index 5d2809de4517..27d11c20d148 100644
--- a/drivers/gpu/drm/drm_exec.c
+++ b/drivers/gpu/drm/drm_exec.c
@@ -69,16 +69,25 @@ static void drm_exec_unlock_all(struct drm_exec *exec)
* drm_exec_init - initialize a drm_exec object
* @exec: the drm_exec object to initialize
* @flags: controls locking behavior, see DRM_EXEC_* defines
+ * @nr: the initial # of objects
*
* Initialize the object and make sure that we can track locked objects.
+ *
+ * If nr is non-zero then it is used as the initial objects table size.
+ * In either case, the table will grow (be re-allocated) on demand.
*/
-void drm_exec_init(struct drm_exec *exec, uint32_t flags)
+void drm_exec_init(s
[Nouveau] [PATCH 0/7] drm/msm/gem: drm_exec conversion
From: Rob Clark Simplify the exec path (removing a legacy optimization) and convert to drm_exec. One drm_exec patch to allow passing in the expected # of GEM objects to avoid re-allocation. I'd be a bit happier if I could avoid the extra objects table allocation in drm_exec in the first place, but wasn't really happy with any of the things I tried to get rid of that. Rob Clark (7): drm/msm/gem: Remove "valid" tracking drm/msm/gem: Remove submit_unlock_unpin_bo() drm/msm/gem: Don't queue job to sched in error cases drm/msm/gem: Split out submit_unpin_objects() helper drm/msm/gem: Cleanup submit_cleanup_bo() drm/exec: Pass in initial # of objects drm/msm/gem: Convert to drm_exec drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 +- drivers/gpu/drm/drm_exec.c | 15 +- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/msm_gem.h | 13 +- drivers/gpu/drm/msm/msm_gem_submit.c| 197 ++-- drivers/gpu/drm/msm/msm_ringbuffer.c| 3 +- drivers/gpu/drm/nouveau/nouveau_exec.c | 2 +- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +- include/drm/drm_exec.h | 2 +- 12 files changed, 79 insertions(+), 170 deletions(-) -- 2.41.0
[Nouveau] [PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
v3: rebased on drm-tip
drivers/gpu/drm/drm_gem.c | 8
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.h | 4 ++--
drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.h | 4 ++--
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++--
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 4 ++--
drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
include/drm/drm_drv.h | 5 ++---
12 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 84689ccae885..af2549c45027 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1215,22 +1215,22 @@ void drm_gem_print_info(struct drm_printer *p, unsigned
int indent,
obj->dev->driver->gem_print_info(p, indent, obj);
}
-int drm_gem_pin(struct drm_gem_object *obj)
+int drm_gem_pin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->pin)
return obj->funcs->pin(obj);
else if (obj->dev->driver->gem_prime_pin)
- return obj->dev->driver->gem_prime_pin(obj);
+ return obj->dev->driver->gem_prime_pin(obj, dev);
else
return 0;
}
-void drm_gem_unpin(struct drm_gem_object *obj)
+void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->unpin)
obj->funcs->unpin(obj);
else if (obj->dev->driver->gem_prime_unpin)
- obj->dev->driver->gem_prime_unpin(obj);
+ obj->dev->driver->gem_prime_unpin(obj, dev);
}
void *drm_gem_vmap(struct drm_gem_object *obj)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 51a2055c8f18..e64090373e3a 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -133,8 +133,8 @@ void drm_gem_release(struct drm_device *dev, struct
drm_file *file_private);
void drm_gem_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *obj);
-int drm_gem_pin(struct drm_gem_object *obj);
-void drm_gem_unpin(struct drm_gem_object *obj);
+int drm_gem_pin(struct drm_gem_object *obj, struct device *dev);
+void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev);
void *drm_gem_vmap(struct drm_gem_object *obj);
void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 189d980402ad..126860432ff9 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -575,7 +575,7 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- return drm_gem_pin(obj);
+ return drm_gem_pin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_attach);
@@ -593,7 +593,7 @@ void drm_gem_map_detach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- drm_gem_unpin(obj);
+ drm_gem_unpin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_detach);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index a05292e8ed6f..67e69a5f00f2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -43,7 +43,7 @@ int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
return etnaviv_obj->ops->mmap(etnaviv_obj, vma);
}
-int etnaviv_gem_prime_pin(struct drm_gem_object *obj)
+int etnaviv_gem_prime_pin(struct drm_gem_object *obj, struct device *dev)
{
if (!obj->import_attach) {
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
@@ -55,7 +55,7 @@ int etnaviv_gem_prime_pin(struct drm_gem_object *obj)
return 0;
}
-void etnaviv_gem_prime_unpin(struct drm_gem_object *obj)
+void etnaviv_gem_prime_unpin(struct drm_gem_object *obj, struct device *dev)
{
if (!obj->import_attach) {
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index ee7b512dc158..0eea68618b68 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -288,8 +288,8 @@ void msm_gem_prime_vunmap(struct drm_gem_object *obj, void
*vaddr);
int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
s
[PATCH v2 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 10 ++
drivers/gpu/drm/drm_gem_vram_helper.c | 6 --
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.h | 4 ++--
drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.h | 4 ++--
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++--
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 4 ++--
drivers/gpu/drm/vboxvideo/vbox_prime.c | 4 ++--
drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
include/drm/drm_drv.h | 4 ++--
include/drm/drm_gem.h | 4 ++--
include/drm/drm_gem_vram_helper.h | 4 ++--
15 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 7d6242cc69f2..0a2645769624 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1219,18 +1219,19 @@ void drm_gem_print_info(struct drm_printer *p, unsigned
int indent,
/**
* drm_gem_pin - Pin backing buffer in memory
* @obj: GEM object
+ * @dev: the device the buffer is being pinned for
*
* Make sure the backing buffer is pinned in memory.
*
* Returns:
* 0 on success or a negative error code on failure.
*/
-int drm_gem_pin(struct drm_gem_object *obj)
+int drm_gem_pin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->pin)
return obj->funcs->pin(obj);
else if (obj->dev->driver->gem_prime_pin)
- return obj->dev->driver->gem_prime_pin(obj);
+ return obj->dev->driver->gem_prime_pin(obj, dev);
else
return 0;
}
@@ -1239,15 +1240,16 @@ EXPORT_SYMBOL(drm_gem_pin);
/**
* drm_gem_unpin - Unpin backing buffer from memory
* @obj: GEM object
+ * @dev: the device the buffer is being pinned for
*
* Relax the requirement that the backing buffer is pinned in memory.
*/
-void drm_gem_unpin(struct drm_gem_object *obj)
+void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->unpin)
obj->funcs->unpin(obj);
else if (obj->dev->driver->gem_prime_unpin)
- obj->dev->driver->gem_prime_unpin(obj);
+ obj->dev->driver->gem_prime_unpin(obj, dev);
}
EXPORT_SYMBOL(drm_gem_unpin);
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 4de782ca26b2..62fafec93948 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -548,7 +548,8 @@ EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
* 0 on success, or
* a negative errno code otherwise.
*/
-int drm_gem_vram_driver_gem_prime_pin(struct drm_gem_object *gem)
+int drm_gem_vram_driver_gem_prime_pin(struct drm_gem_object *gem,
+ struct device *dev)
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
@@ -569,7 +570,8 @@ EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_pin);
Implements &struct drm_driver.gem_prime_unpin
* @gem: The GEM object to unpin
*/
-void drm_gem_vram_driver_gem_prime_unpin(struct drm_gem_object *gem)
+void drm_gem_vram_driver_gem_prime_unpin(struct drm_gem_object *gem,
+struct device *dev)
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d0c01318076b..505893cfac8e 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -196,7 +196,7 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- return drm_gem_pin(obj);
+ return drm_gem_pin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_attach);
@@ -213,7 +213,7 @@ void drm_gem_map_detach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- drm_gem_unpin(obj);
+ drm_gem_unpin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_detach);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 00e8b6a817e3..44385d590aa7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -43,7 +43,7 @@ int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
return etnaviv_obj->ops->mmap(etnaviv_obj, vma);
}
-int etnaviv_gem_prime_pin(struct drm_gem_object *obj)
+int etnaviv_gem_prime_pin(struct drm_gem_object *obj, struct device *dev)
{
if (!obj->import_attac
Re: [Nouveau] [Mesa-dev] Chromium - Application-level nouveau blacklist
On Sat, Jan 5, 2019 at 3:40 PM Ilia Mirkin wrote: > > It looks like as of Chromium 71, nouveau is completely blacklisted. > > I don't really see a way back from this, since they don't cite any > easily reproducible issues, except that some people had some issues > with indeterminate hardware and indeterminate versions of mesa. > > In the bug that triggered this > (https://bugs.chromium.org/p/chromium/issues/detail?id=876523), where > I might have slightly lost my cool, they (at the end) suggested that > we try to make nouveau a first-class citizen with chromium. However I > will never be able to present concrete evidence that inconcrete issues > are resolved. I did run the WebGL CTS suite, but that resulted in some > hangs from the the max-texture-size-equivalent test, and some > browser-level weirdness after some tests where later tests all fail > (due to what I have to assume is a browser bug). I don't think I > managed to properly track down the true reason why. I didn't want to > reach out to them with such results, as that's just further evidence > of nouveau not working perfectly. > > In the meanwhile, end users are losing accelerated WebGL which in > practice worked just fine (at least in my usage of it), and probably > some other functionality. > > One idea is to flip GL_VENDOR to some random string if chromium is > running. I don't like this idea, but I also don't have any great > alternatives. We can also just take this, as yet-another nail in the > nouveau coffin. > I think this would be a really bad idea Better idea might be to request chromium to whitelist nouveau for pairs of nv generation + mesa version that are known to pass (or at least comes reasonably close to passing?) WebGL CTS. Maybe setup a wiki page or trello or bz or whatever w/ some pointers to info about how to disable gpu blacklist (to run the cts tests in the first place) and how to run cts, and table of nv generations. I guess you don't have hw or time to test everything yourself, but this is something that distros and users can help with. The idea for wiki/trello/whatever was to help coordinate that and track open bugs for failing CTS tests. BR, -R ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9
On Thu, Jan 25, 2018 at 8:57 AM, Ilia Mirkin wrote: > On Thu, Jan 25, 2018 at 8:47 AM, Luís Mendes wrote: >> Sorry for alI these individual emails, but I think is more readable >> this way, by having each independent information in a separate email. >> >> I also have these additional cards that I can try: Gefoce GT 1030 and >> Geforce GTX 1050 Ti. >> >> I have tried Geforce GT 1030 and it is working nicely but without >> hardware acceleration. Without the hardware acceleration I am able to >> get into X (Ubuntu Mate 17.10) and run glmark2. >> dmesg follows in attachment. > > This is a GP108 for which you need not-yet-upstream code to get acceleration. > >> >> I believe this indicates there is no issue with cards initialization, >> but is rather something to do with the hardware acceleration code. > > Someone associated with (or working at?) RH was investigating this for > some server-type ARM board with PCIe slots. (Was it you? Rob Clark, > CC'd, will remember who it was, and may be able to point you in an > appropriate direction.) I think that there were various odd issues > with coherency which remained only lightly diagnosed. Note that all > your boots instantaneously print "GPU lockup, have a nice day". > Everything after that is largely irrelevant. well, I don't actually have any ARM board w/ PCIe yet.. although I would expect that drm_cflush* being no-ops on arm/arm64 isn't likely to help things. BR, -R > This happens when it tries to execute some very basic things and sees > that there is no progress. This means sticking a command buffer on the > DMA ring, letting the GPU execute it, and making sure that the fence > is hit as seen by the CPU. I would recommend tracking down why the > accel doesn't work (i.e. you get that message), and not worry about > little details like "image appears on screen". > > Unfortunately the initialization logic in nouveau is a giant pile of > spaghetti (with various arguably good reasons, but it doesn't change > the end result), so tracking down exactly what fails in the GPU init > will be a bit of an undertaking. You should join #nouveau on > irc.freenode.net and get some additional advice there. > > Good luck, > > -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Interested in writing an Instruction Scheduler for Nouveau (X.Org)
On Tue, Dec 26, 2017 at 2:15 AM, Neha Gupta wrote: > Greetings all, > > I have been looking at the X.Org ideas page and the project " Instruction > Scheduler for Nouveau" caught my eye. I'm learning about Operating Systems > for 8 months in academics course and udacity linux and operating system > courses, and thus the idea seems interesting. Also, I’ve been working on a > Rust based file-system in intermezzOS project and applied to GSoC under > intermezzOS, which is an OS built using rust. Since it wasn’t completely a > Mozilla project proposal but was using rust as a programming language, > Mozilla took the proposal but didn’t have sufficient slots for a non-Mozilla > project during GSoC. I have some questions: > > 1. Where can I get started from (repository link) or some initial bug fixes? The mesa codebase is at: git://anongit.freedesktop.org/mesa/mesa https://cgit.freedesktop.org/mesa/mesa/ The shader compiler in particular is under src/gallium/drivers/nouveau/codegen/ > 2. What would be the primary mode of communication? (IRC/slack..) IRC (freenode, #dri-devel and #nouveau) As far as mailing lists, mesa-...@lists.freedesktop.org and nouveau@lists.freedesktop.org > 3. I've been shortlisted for GSoC (under CERN) and Outreachy Round 15 (under > Mediawiki) projects but couldn't get selected due to my enrollment in a > full-time academic course. Will that be an issue in X.Org as well? Yes, EVoC doesn't have a fixed timeline like GSoC, but it does require 3-4 months of vacation where you would be able to work nearly full time on the project. BR, -R ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/disp/gf119: add missing drive vfunc ptr
On Sat, Jan 6, 2018 at 10:59 AM, Rob Clark wrote:
> Fixes broken dp on GF119:
>
> Call Trace:
>? nvkm_dp_train_drive+0x183/0x2c0 [nouveau]
>nvkm_dp_acquire+0x4f3/0xcd0 [nouveau]
>nv50_disp_super_2_2+0x5d/0x470 [nouveau]
>? nvkm_devinit_pll_set+0xf/0x20 [nouveau]
>gf119_disp_super+0x19c/0x2f0 [nouveau]
>process_one_work+0x193/0x3c0
>worker_thread+0x35/0x3b0
>kthread+0x125/0x140
>? process_one_work+0x3c0/0x3c0
>? kthread_park+0x60/0x60
>ret_from_fork+0x25/0x30
> Code: Bad RIP value.
> RIP: (null) RSP: b1e243e4bc38
> CR2:
>
> Fixes: af85389c614a drm/nouveau/disp: shuffle functions around
This should probably also have:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103421
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
> index a2978a37b4f3..700fc754f28a 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
> @@ -174,6 +174,7 @@ gf119_sor = {
> .links = gf119_sor_dp_links,
> .power = g94_sor_dp_power,
> .pattern = gf119_sor_dp_pattern,
> + .drive = gf119_sor_dp_drive,
> .vcpi = gf119_sor_dp_vcpi,
> .audio = gf119_sor_dp_audio,
> .audio_sym = gf119_sor_dp_audio_sym,
> --
> 2.14.3
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau/disp/gf119: add missing drive vfunc ptr
Fixes broken dp on GF119:
Call Trace:
? nvkm_dp_train_drive+0x183/0x2c0 [nouveau]
nvkm_dp_acquire+0x4f3/0xcd0 [nouveau]
nv50_disp_super_2_2+0x5d/0x470 [nouveau]
? nvkm_devinit_pll_set+0xf/0x20 [nouveau]
gf119_disp_super+0x19c/0x2f0 [nouveau]
process_one_work+0x193/0x3c0
worker_thread+0x35/0x3b0
kthread+0x125/0x140
? process_one_work+0x3c0/0x3c0
? kthread_park+0x60/0x60
ret_from_fork+0x25/0x30
Code: Bad RIP value.
RIP: (null) RSP: b1e243e4bc38
CR2:
Fixes: af85389c614a drm/nouveau/disp: shuffle functions around
Signed-off-by: Rob Clark
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
index a2978a37b4f3..700fc754f28a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
@@ -174,6 +174,7 @@ gf119_sor = {
.links = gf119_sor_dp_links,
.power = g94_sor_dp_power,
.pattern = gf119_sor_dp_pattern,
+ .drive = gf119_sor_dp_drive,
.vcpi = gf119_sor_dp_vcpi,
.audio = gf119_sor_dp_audio,
.audio_sym = gf119_sor_dp_audio_sym,
--
2.14.3
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm: remove NULL pointer check for clk_disable_unprepare
On Sat, May 20, 2017 at 3:04 PM, Masahiro Yamada wrote: > 2017-05-21 2:58 GMT+09:00 Masahiro Yamada : >> After long term efforts of fixing non-common clock implementations, >> clk_disable() is a no-op for a NULL pointer input, and this is now >> tree-wide consistent. >> >> All clock consumers can safely call clk_disable(_unprepare) without >> NULL pointer check. >> >> Signed-off-by: Masahiro Yamada > > > Sorry, I retract this patch. > > Krzysztof pointed out > cleanups only for clk_disable_unprepare() will lose the code symmetry. > > NULL pointer checks for clk_prepare_enable() should be > removed to keep the code symmetrical. > > This is possible for common-clock framework because > clk_prepare_enable() is also a no-op for a NULL clk input. > But it is not necessarily true for non-common clock implementations. At least for drm/msm, upstream I think we can assume CCF.. I still need to check for possible downstream kernels to which someone might want to backport drm/msm. It might be an idea to split this up per-driver, since at least for some drivers it might be safe to assume CCF (or non-CCF clk driver that behaves the same) BR, -R > > -- > Best Regards > Masahiro Yamada ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_
On Tue, Feb 28, 2017 at 7:55 AM, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
for drm/msm part:
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 -
> drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
> drivers/gpu/drm/gma500/psb_drv.h | 5 ++---
> drivers/gpu/drm/gma500/psb_intel_lvds.c | 7 +++
> drivers/gpu/drm/i915/i915_sw_fence.c | 8
> drivers/gpu/drm/mgag200/mgag200_mode.c| 2 +-
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_acpi.c| 7 ---
> drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++--
> drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
> drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
> drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
> drivers/gpu/drm/omapdrm/dss/dss.c | 3 +--
> drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
> drivers/gpu/drm/omapdrm/omap_gem.c| 5 ++---
> drivers/gpu/drm/r128/r128_cce.c | 7 +++
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
> 20 files changed, 72 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder
> *encoder,
> head) {
> if (tmp_encoder != encoder
> && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> - "encoder on the same pipe\n");
> + pr_err("Can't enable LVDS and another encoder on the
> same pipe\n");
> return false;
> }
> }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>
> failed_find:
> mutex_unlock(&dev->mode_config.mutex);
> - printk(KERN_ERR "Failed find\n");
> + pr_err("Failed find\n");
> psb_intel_i2c_destroy(gma_encoder->ddc_bus);
> failed_ddc:
> - printk(KERN_ERR "Failed DDC\n");
> + pr_err("Failed DDC\n");
> psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> failed_blc_i2c:
> - printk(KERN_ERR "Failed BLC\n");
> + pr_err("Failed BLC\n");
> drm_encoder_cleanup(encoder);
> drm_connector_cleanup(connector);
> kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct
> drm_device *dev,
> ((ti->vblank_hi << 8) | ti->vblank_lo);
> mode->clock = ti->pixel_clock * 10;
> #if 0
> - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> - printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> - printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> - printk(KERN_INFO "htotal is %d\n", mode->htotal);
> - printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> - printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> - printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> - printk(KERN_INFO "clock is %d\n", mode->clock);
> + pr_info("hdisplay is %d\n", mode->hdisplay);
> + pr_info("vdisplay is %d\n", mode->vdisplay);
> + pr_info("HSS is %d\n", mode->hsync_start);
> + pr_info("HSE is %d\n", mode->hsync_end);
> + pr_info("htotal is %d\n", mode->htotal);
> +
Re: [Nouveau] [Mesa-dev] [RFC] tegra: Initial support
On Thu, Nov 27, 2014 at 11:39 AM, Thierry Reding wrote: > Tegra K1 and later use a GPU that can be driven by the Nouveau driver. > But the GPU is a pure render node and has no display engine, hence the > scanout needs to happen on the Tegra display hardware. The GPU and the > display engine each have a separate DRM device node exposed by the > kernel. > > To make the setup appear as a single device, this driver instantiates > a Nouveau screen with each instance of a Tegra screen and forwards GPU > requests to the Nouveau screen. For purposes of scanout it will import > buffers created on the GPU into the display driver. Handles that > userspace requests are those of the display driver so that they can be > used to create framebuffers. > > This has been tested with some GBM test programs, as well as kmscube and > weston. All of those run without modifications, but I'm sure there is a > lot that can be improved. > > TODO: > - use Nouveau headers to get at the prototype for creating a screen > - implement enough support to seamlessly integrate with X > - refactor some of the code to be reusable by other drivers I haven't looked too carefully at the implementation yet, but couldn't you just put in src/gallium/drivers/shim ? I guess you'd just want a small if/else ladder where you create the *actual* screen, to create a nouveau screen for tegra, an etnaviv screen for imx, armada, etc..? BR, -R > > Signed-off-by: Thierry Reding > --- > configure.ac | 12 +- > src/gallium/Makefile.am| 5 + > .../auxiliary/target-helpers/inline_drm_helper.h | 30 + > src/gallium/drivers/tegra/Automake.inc | 11 + > src/gallium/drivers/tegra/Makefile.am | 17 + > src/gallium/drivers/tegra/Makefile.sources | 4 + > src/gallium/drivers/tegra/tegra_context.c | 699 > + > src/gallium/drivers/tegra/tegra_context.h | 80 +++ > src/gallium/drivers/tegra/tegra_resource.c | 219 +++ > src/gallium/drivers/tegra/tegra_resource.h | 98 +++ > src/gallium/drivers/tegra/tegra_screen.c | 311 + > src/gallium/drivers/tegra/tegra_screen.h | 45 ++ > src/gallium/targets/dri/Makefile.am| 2 + > src/gallium/winsys/tegra/drm/Makefile.am | 11 + > src/gallium/winsys/tegra/drm/Makefile.sources | 2 + > src/gallium/winsys/tegra/drm/tegra_drm_public.h| 31 + > src/gallium/winsys/tegra/drm/tegra_drm_winsys.c| 33 + > 17 files changed, 1609 insertions(+), 1 deletion(-) > create mode 100644 src/gallium/drivers/tegra/Automake.inc > create mode 100644 src/gallium/drivers/tegra/Makefile.am > create mode 100644 src/gallium/drivers/tegra/Makefile.sources > create mode 100644 src/gallium/drivers/tegra/tegra_context.c > create mode 100644 src/gallium/drivers/tegra/tegra_context.h > create mode 100644 src/gallium/drivers/tegra/tegra_resource.c > create mode 100644 src/gallium/drivers/tegra/tegra_resource.h > create mode 100644 src/gallium/drivers/tegra/tegra_screen.c > create mode 100644 src/gallium/drivers/tegra/tegra_screen.h > create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am > create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources > create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h > create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c > > diff --git a/configure.ac b/configure.ac > index 1d9d015481ec..ae50bec95339 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -33,6 +33,7 @@ LIBDRM_INTEL_REQUIRED=2.4.52 > LIBDRM_NVVIEUX_REQUIRED=2.4.33 > LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41" > LIBDRM_FREEDRENO_REQUIRED=2.4.57 > +LIBDRM_TEGRA_REQUIRED=2.4.58 > DRI2PROTO_REQUIRED=2.6 > DRI3PROTO_REQUIRED=1.0 > PRESENTPROTO_REQUIRED=1.0 > @@ -733,7 +734,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast" > AC_ARG_WITH([gallium-drivers], > [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@], > [comma delimited Gallium drivers list, e.g. > -"i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,vc4" > +"i915,ilo,nouveau,r300,r600,radeonsi,freedreno,tegra,svga,swrast,vc4" > @<:@default=r300,r600,svga,swrast@:>@])], > [with_gallium_drivers="$withval"], > [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"]) > @@ -1937,6 +1938,12 @@ if test -n "$with_gallium_drivers"; then > gallium_require_drm "freedreno" > gallium_require_drm_loader > ;; > +xtegra) > +HAVE_GALLIUM_TEGRA=yes > +PKG_CHECK_MODULES([TEGRA], [libdrm_tegra >= > $LIBDRM_TEGRA_REQUIRED]) > +gallium_require_drm "tegra" > +gallium_require_drm_loader > +;; > xswrast) > HAVE_GALLIUM_SOFTPIPE=yes > if test "x$MESA_LLVM" = x1; then > @@ -2018,6 +2025,7 @@ AM_CONDITIONAL(HAVE_GALLIUM_RADEON_COMMON, test
Re: [Nouveau] [PATCH libdrm] configure: Support symbol visibility when available
On Wed, Jul 30, 2014 at 10:37 AM, Emil Velikov wrote:
> On 30/07/14 15:31, Rob Clark wrote:
>> On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding
>> wrote:
>>> From: Thierry Reding
>>>
>>> Checks whether or not the compiler supports the -fvisibility option. If
>>> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
>>> directory AM_CFLAGS where appropriate.
>>>
>>> By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
>>> drm_public macro can be used to mark symbols that should be exported.
>>
>> hmm, maybe dumb question, I might possibly have missed some discussion
>> on this, but if we merged this without a heap of patches to export
>> libdrm and libdrm_foo syms, wouldn't everything be hidden?
>>
>> Maybe we should introduce drm_public first.. then once stuff is
>> converted to use it actually start hiding things?
>>
> This adds the tool, but it's up-to the individual libraries/makefiles to make
> use of it.
>
> All you need is:
> - append $(VISIBILITY_CFLAGS) to libdrm_freedreno_CFLAGS
> - prefix each exported function definition with DRM_PUBLIC
> - ***
> - profit :P
ahh, ok, that makes much more sense.. thx :-)
BR,
-R
> -Emil
>
>>
>> BR,
>> -R
>>
>>> Signed-off-by: Thierry Reding
>>> ---
>>> Changes in v3:
>>> - distribute libdrm.h
>>>
>>> Makefile.am | 1 +
>>> configure.ac | 20
>>> libdrm.h | 34 ++
>>> 3 files changed, 55 insertions(+)
>>> create mode 100644 libdrm.h
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index 826c30d0c0d9..65680da963eb 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -69,6 +69,7 @@ libdrm_la_SOURCES = \
>>> xf86drmSL.c \
>>> xf86drmMode.c \
>>> xf86atomic.h\
>>> + libdrm.h\
>>> libdrm_lists.h
>>>
>>> libdrmincludedir = ${includedir}
>>> diff --git a/configure.ac b/configure.ac
>>> index 1c78c4520c49..f7c7177bfb2a 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -366,6 +366,26 @@ AC_ARG_WITH([kernel-source],
>>> [kernel_source="$with_kernel_source"])
>>> AC_SUBST(kernel_source)
>>>
>>> +dnl Add flags for gcc and g++
>>> +if test "x$GCC" = xyes; then
>>> +# Enable -fvisibility=hidden if using a gcc that supports it
>>> +save_CFLAGS="$CFLAGS"
>>> +AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
>>> +VISIBILITY_CFLAGS="-fvisibility=hidden"
>>> +CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
>>> +AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
>>> + [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
>>> +
>>> +# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
>>> +CFLAGS=$save_CFLAGS
>>> +
>>> +if test "x$VISIBILITY_CFLAGS" != x; then
>>> +AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler has -fvisibility support])
>>> +fi
>>> +
>>> +AC_SUBST([VISIBILITY_CFLAGS])
>>> +fi
>>> +
>>> AC_SUBST(WARN_CFLAGS)
>>> AC_CONFIG_FILES([
>>> Makefile
>>> diff --git a/libdrm.h b/libdrm.h
>>> new file mode 100644
>>> index ..23926e6f6741
>>> --- /dev/null
>>> +++ b/libdrm.h
>>> @@ -0,0 +1,34 @@
>>> +/*
>>> + * Copyright © 2014 NVIDIA Corporation
>>> + *
>>> + * Permission is hereby granted, free of charge, to any person obtaining a
>>> + * copy of this software and associated documentation files (the
>>> "Software"),
>>> + * to deal in the Software without restriction, including without
>>> limitation
>>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>>> + * and/or sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be included
>>> in
>>> + * all copies or substantial portions of the Software.
>>> + *
>>>
Re: [Nouveau] [PATCH libdrm] configure: Support symbol visibility when available
On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Checks whether or not the compiler supports the -fvisibility option. If
> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
> directory AM_CFLAGS where appropriate.
>
> By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
> drm_public macro can be used to mark symbols that should be exported.
hmm, maybe dumb question, I might possibly have missed some discussion
on this, but if we merged this without a heap of patches to export
libdrm and libdrm_foo syms, wouldn't everything be hidden?
Maybe we should introduce drm_public first.. then once stuff is
converted to use it actually start hiding things?
BR,
-R
> Signed-off-by: Thierry Reding
> ---
> Changes in v3:
> - distribute libdrm.h
>
> Makefile.am | 1 +
> configure.ac | 20
> libdrm.h | 34 ++
> 3 files changed, 55 insertions(+)
> create mode 100644 libdrm.h
>
> diff --git a/Makefile.am b/Makefile.am
> index 826c30d0c0d9..65680da963eb 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -69,6 +69,7 @@ libdrm_la_SOURCES = \
> xf86drmSL.c \
> xf86drmMode.c \
> xf86atomic.h\
> + libdrm.h\
> libdrm_lists.h
>
> libdrmincludedir = ${includedir}
> diff --git a/configure.ac b/configure.ac
> index 1c78c4520c49..f7c7177bfb2a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -366,6 +366,26 @@ AC_ARG_WITH([kernel-source],
> [kernel_source="$with_kernel_source"])
> AC_SUBST(kernel_source)
>
> +dnl Add flags for gcc and g++
> +if test "x$GCC" = xyes; then
> +# Enable -fvisibility=hidden if using a gcc that supports it
> +save_CFLAGS="$CFLAGS"
> +AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
> +VISIBILITY_CFLAGS="-fvisibility=hidden"
> +CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
> +AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
> + [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
> +
> +# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
> +CFLAGS=$save_CFLAGS
> +
> +if test "x$VISIBILITY_CFLAGS" != x; then
> +AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler has -fvisibility support])
> +fi
> +
> +AC_SUBST([VISIBILITY_CFLAGS])
> +fi
> +
> AC_SUBST(WARN_CFLAGS)
> AC_CONFIG_FILES([
> Makefile
> diff --git a/libdrm.h b/libdrm.h
> new file mode 100644
> index ..23926e6f6741
> --- /dev/null
> +++ b/libdrm.h
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright © 2014 NVIDIA Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef LIBDRM_LIBDRM_H
> +#define LIBDRM_LIBDRM_H
> +
> +#if defined(HAVE_VISIBILITY)
> +# define drm_private __attribute__((visibility("hidden")))
> +# define drm_public __attribute__((visibility("default")))
> +#else
> +# define drm_private
> +# define drm_public
> +#endif
> +
> +#endif
> --
> 2.0.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences
On Wed, Jul 23, 2014 at 2:52 AM, Christian König wrote: > Am 23.07.2014 08:40, schrieb Maarten Lankhorst: > >> op 22-07-14 17:59, Christian König schreef: >>> >>> Am 22.07.2014 17:42, schrieb Daniel Vetter: On Tue, Jul 22, 2014 at 5:35 PM, Christian König wrote: > > Drivers exporting fences need to provide a fence->signaled and a > fence->wait > function, everything else like fence->enable_signaling or calling > fence_signaled() from the driver is optional. > > Drivers wanting to use exported fences don't call fence->signaled or > fence->wait in atomic or interrupt context, and not with holding any > global > locking primitives (like mmap_sem etc...). Holding locking primitives > local > to the driver is ok, as long as they don't conflict with anything > possible > used by their own fence implementation. Well that's almost what we have right now with the exception that drivers are allowed (actually must for correctness when updating fences) the ww_mutexes for dma-bufs (or other buffer objects). >>> >>> In this case sorry for so much noise. I really haven't looked in so much >>> detail into anything but Maarten's Radeon patches. >>> >>> But how does that then work right now? My impression was that it's >>> mandatory for drivers to call fence_signaled()? >> >> It's only mandatory to call fence_signal() if the .enable_signaling >> callback has been called, else you can get away with never calling signaling >> a fence at all before dropping the last refcount to it. >> This allows you to keep interrupts disabled when you don't need them. > > > Can we somehow avoid the need to call fence_signal() at all? The interrupts > at least on radeon are way to unreliable for such a thing. Can > enable_signalling fail? What's the reason for fence_signaled() in the first > place? > the device you are sharing with may not be able to do hw<->hw signalling.. think about buffer sharing w/ camera, for example. You probably want your ->enable_signalling() to enable whatever workaround periodic-polling you need to do to catch missed irq's (and then call fence->signal() once you detect the fence has passed. fwiw, I haven't had a chance to read this whole thread yet, but I expect that a lot of the SoC devices, especially ones with separate kms-only display and gpu drivers, will want callback from gpu's irq to bang a few display controller registers. I agree in general callbacks from atomic ctx is probably something you want to avoid, but in this particular case I think it is worth the extra complexity. Nothing is stopping a driver from using a callback that just chucks something on a workqueue, whereas the inverse is not possible. BR, -R > Agreed that any shared locks are out of the way (especially stuff like dev->struct_mutex or other non-strictly driver-private stuff, i915 is really bad here still). >>> >>> Yeah that's also an point I've wanted to note on Maartens patch. Radeon >>> grabs the read side of it's exclusive semaphore while waiting for fences >>> (because it assumes that the fence it waits for is a Radeon fence). >>> >>> Assuming that we need to wait in both directions with Prime (e.g. Intel >>> driver needs to wait for Radeon to finish rendering and Radeon needs to wait >>> for Intel to finish displaying), this might become a perfect example of >>> locking inversion. >> >> In the preliminary patches where I can sync radeon with other GPU's I've >> been very careful in all the places that call into fences, to make sure that >> radeon wouldn't try to handle lockups for a different (possibly also radeon) >> card. > > > That's actually not such a good idea. > > In case of a lockup we need to handle the lockup cause otherwise it could > happen that radeon waits for the lockup to be resolved and the lockup > handling needs to wait for a fence that's never signaled because of the > lockup. > > Christian. > > >> >> This is also why fence_is_signaled should never block, and why it trylocks >> the exclusive_lock. :-) I think lockdep would complain if I grabbed >> exclusive_lock while blocking in is_signaled. >> So from the core fence framework I think we already have exactly this, and we only need to adjust the radeon implementation a bit to make it less risky and invasive to the radeon driver logic. >>> >>> Agree. Well the biggest problem I see is that exclusive semaphore I need >>> to take when anything calls into the driver. For the fence code I need to >>> move that down into the fence->signaled handler, cause that now can be >>> called from outside the driver. >>> >>> Maarten solved this by telling the driver in the lockup handler (where we >>> grab the write side of the exclusive lock) that all interrupts are already >>> enabled, so that fence->signaled hopefully wouldn't mess with the hardware >>> at all. While this probably works, it just leaves me with a feeling that we >>> are doing somethin
Re: [Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers
On Thu, Jun 26, 2014 at 7:17 PM, Alexandre Courbot wrote: > On Fri, Jun 27, 2014 at 1:10 AM, Russell King - ARM Linux > wrote: >> On Thu, Jun 26, 2014 at 11:53:20PM +0900, Alexandre Courbot wrote: >>> We don't plan to rely on CMA for too long. IOMMU support is on the way >>> and should make our life easier, although no matter the source of >>> memory, we will still have the issue of the lowmem mappings. >> >> When it comes to DMA memory, talking about lowmem vs highmem is utterly >> meaningless. >> >> The lowmem/highmem split is entirely a software concept and is completely >> adjustable. An extreme example is that you can boot any platform with >> more than 32MB of memory with 32MB of lowmem and the remainder as >> highmem. > > True, but isn't it also the case that all lowmem is already mapped in > the kernel address space, and that re-mapping this memory with > different cache settings (e.g. by creating a WC mapping for user-space > to write into) is undefined on ARM and must be avoided? That is the > issue I was referring to. > dma memory should be removed from the kernel linear map (if needed).. assuming it is allocated w/ dma api's. btw, something I've been wondering for a little while, but haven't had time to investigate. Not sure if this applies to you as well. But seems like I have IOMMU's which can be outer-coherent (snoop L2), but I *think* they are not inner-coherent (L1). No idea if current dma memory code can grok this and only do inner-cache op's.. BR, -R > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
