search for: nvif_notify_init

There is no reason to not free the notify data if the NTFY_DEL ioctl failed. As nvif_notify_fini() is also called from the cleanup path of nvif_notify_init(), the notifier may not have been successfully created at that point. But it should also be the right thing to just free the data in the regular fini calls, as there is nothing much we can do if the ioctl fails, so better not leak memory. Signed-off-by: Lucas Stach <dev at lynxeye.de> --- d...

...14 @@ nouveau_connector_create(struct drm_device *dev, int index) break; } + switch (type) { + case DRM_MODE_CONNECTOR_DisplayPort: + case DRM_MODE_CONNECTOR_eDP: + drm_dp_cec_register_connector(&nv_connector->aux, + connector->name, dev->dev); + break; + } + ret = nvif_notify_init(&disp->disp.object, nouveau_connector_hotplug, true, NV04_DISP_NTFY_CONN, &(struct nvif_notify_conn_req_v0) { -- 2.18.0

...14 @@ nouveau_connector_create(struct drm_device *dev, int index) break; } + switch (type) { + case DRM_MODE_CONNECTOR_DisplayPort: + case DRM_MODE_CONNECTOR_eDP: + drm_dp_cec_register_connector(&nv_connector->aux, + connector->name, dev->dev); + break; + } + ret = nvif_notify_init(&disp->disp.object, nouveau_connector_hotplug, true, NV04_DISP_NTFY_CONN, &(struct nvif_notify_conn_req_v0) { -- 2.18.0

...>] ? warn_slowpath_null+0x1a/0x20 :[<ffffffffa00e35b6>] ? drm_helper_choose_crtc_dpms+0xa6/0xb0 [drm_kms_helper] :[<ffffffffa00e40d6>] ? drm_helper_connector_dpms+0xe6/0x1a0 [drm_kms_helper] :[<ffffffffa01e1e80>] ? nv50_crtc_dpms+0x0/0x10 [nouveau] :[<ffffffffa0134f01>] ? nvif_notify_init+0x121/0x160 [nouveau] :[<ffffffffa01dfe42>] ? nouveau_connector_hotplug+0x92/0xd0 [nouveau] :[<ffffffffa0134f40>] ? nvif_notify_work+0x0/0xc0 [nouveau] :[<ffffffffa0134f6e>] ? nvif_notify_work+0x2e/0xc0 [nouveau] :[<ffffffffa01ecf10>] ? nouveau_fence_work_handler+0x0/0x30 [n...

...,14 @@ nouveau_connector_create(struct drm_device *dev, int index) break; } + switch (type) { + case DRM_MODE_CONNECTOR_DisplayPort: + case DRM_MODE_CONNECTOR_eDP: + drm_dp_cec_register_connector(&nv_connector->aux, + connector->name, dev->dev); + break; + } + ret = nvif_notify_init(&disp->disp.object, nouveau_connector_hotplug, true, NV04_DISP_NTFY_CONN, &(struct nvif_notify_conn_req_v0) { -- 2.18.0

From: Hans Verkuil <hans.verkuil at cisco.com> Repost because I wasn't a member of the nouveau mailinglist the first time around and this series was blocked. I also updated this cover letter for the part about the amdgpu patch after receiving feedback from Alex Deucher. The patches are unchanged (except for adding Alex' Acked-by to the amdgpu patch). Now that the DisplayPort

From: Hans Verkuil <hans.verkuil at cisco.com> Now that the DisplayPort CEC-Tunneling-over-AUX drm+i915 support has been merged in the mainline kernel it is time to roll this out to nouveau and amdgpu as well. The first patch is required for this: it adds checks that the drm_dp_cec functions are called with a working aux implementation. These checks weren't necessary for the i915, but

...+} + int nv04_crtc_create(struct drm_device *dev, int crtc_num) { + struct nouveau_display *disp = nouveau_display(dev); struct nouveau_crtc *nv_crtc; int ret; @@ -1337,5 +1351,14 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) nv04_cursor_init(nv_crtc); - return 0; + ret = nvif_notify_init(&disp->disp.object, nv04_crtc_vblank_handler, + false, NV04_DISP_NTFY_VBLANK, + &(struct nvif_notify_head_req_v0) { + .head = nv_crtc->index, + }, + sizeof(struct nvif_notify_head_req_v0), + sizeof(struct nvif_notify_head_rep_v0), +...

...+} + int nv04_crtc_create(struct drm_device *dev, int crtc_num) { + struct nouveau_display *disp = nouveau_display(dev); struct nouveau_crtc *nv_crtc; int ret; @@ -1336,5 +1350,14 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) nv04_cursor_init(nv_crtc); - return 0; + ret = nvif_notify_init(&disp->disp.object, nv04_crtc_vblank_handler, + false, NV04_DISP_NTFY_VBLANK, + &(struct nvif_notify_head_req_v0) { + .head = nv_crtc->index, + }, + sizeof(struct nvif_notify_head_req_v0), + sizeof(struct nvif_notify_head_rep_v0), +...

...+} + int nv04_crtc_create(struct drm_device *dev, int crtc_num) { + struct nouveau_display *disp = nouveau_display(dev); struct nouveau_crtc *nv_crtc; int ret; @@ -1336,5 +1350,14 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) nv04_cursor_init(nv_crtc); - return 0; + ret = nvif_notify_init(&disp->disp.object, nv04_crtc_vblank_handler, + false, NV04_DISP_NTFY_VBLANK, + &(struct nvif_notify_head_req_v0) { + .head = nv_crtc->index, + }, + sizeof(struct nvif_notify_head_req_v0), + sizeof(struct nvif_notify_head_rep_v0), +...

...+} + int nv04_crtc_create(struct drm_device *dev, int crtc_num) { + struct nouveau_display *disp = nouveau_display(dev); struct nouveau_crtc *nv_crtc; int ret; @@ -1336,5 +1350,14 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) nv04_cursor_init(nv_crtc); - return 0; + ret = nvif_notify_init(&disp->disp.object, nv04_crtc_vblank_handler, + false, NV04_DISP_NTFY_VBLANK, + &(struct nvif_notify_head_req_v0) { + .head = nv_crtc->index, + }, + sizeof(struct nvif_notify_head_req_v0), + sizeof(struct nvif_notify_head_rep_v0), +...

https://bugs.freedesktop.org/show_bug.cgi?id=92307 Bug ID: 92307 Summary: NV50: WARNING: ... at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]() Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

From: Hans Verkuil <hans.verkuil at cisco.com> Now that the DisplayPort CEC-Tunneling-over-AUX drm+i915 support has been merged in the mainline kernel it is time to roll this out to nouveau and amdgpu as well. I combined both in the same patch series since both depend on the same first patch, the comments in this cover letter apply to both and the implementation is also very similar (and

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Hi there, Resending these now that they've had some more polish and testing, and I heard that Ben's vacation is over :-) These patches work as a starting point for more explicit error mechanisms and better robustness. At the moment, when a job hangs or faults, it seems that nouveau doesn't quite know how to handle the situation and often results in a hang. Some of these situations