search for: nv50_bo_move_init

..._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 be NV84-compatible...

..._bo_copy_init }, - { "COPY0", 4, 0x90b5, nvc0_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(...

...ruct { + static const struct _method_table { const char *name; int engine; s32 oclass; @@ -1192,7 +1192,8 @@ nouveau_bo_move_init(struct nouveau_drm *drm) { "M2MF", 0, 0x0039, nv04_bo_move_m2mf, nv04_bo_move_init }, {}, { "CRYPT", 0, 0x88b4, nv98_bo_move_exec, nv50_bo_move_init }, - }, *mthd = _methods; + }; + const struct _method_table *mthd = _methods; const char *name = "CPU"; int ret; -- 2.17.1

...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/archives/nouveau/atta...

...ouveau_cli *cli, u64 size, int align, u32 flags, int nv04_bo_move_init(struct nouveau_channel *, u32); int nv04_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 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 *, -...

...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 userspace from using PC...

...; int nv04_bo_move_init(struct nouveau_channel *, u32); > int nv04_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 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...