search for: nv84_bo_move_exec

...839,7 @@ nouveau_bo_move_init(struct nouveau_channel *chan) } _methods[] = { { "COPY", 0xa0b5, nve0_bo_move_copy, nvc0_bo_move_init }, { "M2MF", 0x9039, nvc0_bo_move_m2mf, nvc0_bo_move_init }, + { "CRYPT", 0x74c1, nv84_bo_move_exec, nv50_bo_move_init }, { "M2MF", 0x5039, nv50_bo_move_m2mf, nv50_bo_move_init }, { "M2MF", 0x0039, nv04_bo_move_m2mf, nv04_bo_move_init }, at the heart of the issue, I think we now have the question whether it indeed is correct that there might...

...struct ttm_resource *, struct ttm_resource *); int nv50_bo_move_init(struct nouveau_channel *, u32); int nv50_bo_move_m2mf(struct nouveau_channel *, struct ttm_buffer_object *, - struct ttm_mem_reg *, struct ttm_mem_reg *); + struct ttm_resource *, struct ttm_resource *); int nv84_bo_move_exec(struct nouveau_channel *, struct ttm_buffer_object *, - struct ttm_mem_reg *, struct ttm_mem_reg *); + struct ttm_resource *, struct ttm_resource *); int nva3_bo_move_copy(struct nouveau_channel *, struct ttm_buffer_object *, - struct ttm_mem_reg *, struct ttm_mem_reg *); +...

...; int nv50_bo_move_init(struct nouveau_channel *, u32); > int nv50_bo_move_m2mf(struct nouveau_channel *, struct ttm_buffer_object *, > - struct ttm_mem_reg *, struct ttm_mem_reg *); > + struct ttm_resource *, struct ttm_resource *); > > int nv84_bo_move_exec(struct nouveau_channel *, struct ttm_buffer_object *, > - struct ttm_mem_reg *, struct ttm_mem_reg *); > + struct ttm_resource *, struct ttm_resource *); > > int nva3_bo_move_copy(struct nouveau_channel *, struct ttm_buffer_object *, > -...

...ure set implemented by these early G86 cards and how to properly activate these features directly to NVidia (AFAIK, they recently offered some help by answering questions from nouveau developers)? In order to move forward, I will try to comment out the single line { "CRYPT", 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init }, in a current 3.12.4 build, and report back on what happens... Best regards, Andreas -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/ar...

..._bo_move_copy, nvc0_bo_copy_init }, +// { "COPY1", 5, 0x90b8, nvc0_bo_move_copy, nvc0_bo_copy_init }, +// { "COPY0", 4, 0x90b5, nvc0_bo_move_copy, nvc0_bo_copy_init }, { "COPY", 0, 0x85b5, nva3_bo_move_copy, nv50_bo_move_init }, { "CRYPT", 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init }, { "M2MF", 0, 0x9039, nvc0_bo_move_m2mf, nvc0_bo_m2mf_init }, @@ -1166,13 +1164,23 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) { struct nouveau_bo *nvbo = nouveau_bo(bo); struct nouveau_vma *vma; + struct ttm_mem_reg *ol...

.... On this version, 285.09 still ran fine. What exactly would you want me to check with the "blob"? Is there any diagnostic tool that could check about my "vdec clock" or pcrypt status? In the meantime, I have verified that with the single line { "CRYPT", 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init }, commented out, a 3.12.4 kernel works fine - no corruption seen. > So, in order to completely disable PCRYPT without patching your system you > can boot with "nouveau.config=PCRYPT=0" in your kernel cmdline (since 3.7, I > think). It will also disallow user...