dri-devel September 2018

dri-devel@lists.freedesktop.org

276 participants
1899 discussions

[PATCH 0/2] [radeon] Getting rid of GUP and use HMM for user ptr features.
by jglisse＠redhat.com 10 Sep '18

10 Sep '18

From: Jérôme Glisse <jglisse(a)redhat.com> [This depends on some HMM patchset queued upstream see branch [1]] This is simple change to switch to use HMM for user ptr buffer object which conveniently avoid to pin pages. I have more things in the pipe to make HMM more usefull for such cases (like sharing more resources accross multiple mirror of a same process). Beside avoiding pining, this is also an attempt to isolate core mm from device drivers by having clearly define API and boundary where we can set expection of everyone and thus having mm folks to have to read and understand driver code and conversly having driver folks understand mm maze. This is also part of what i want to discuss during XDC2018. Consider this as an RFC to start the discussion. [1] https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-radeon-v00 Cc: dri-devel(a)lists.freedesktop.org Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Felix Kuehling <Felix.Kuehling(a)amd.com> Cc: David (ChunMing) Zhou <David1.Zhou(a)amd.com> Cc: Nicolai Hähnle <nicolai.haehnle(a)amd.com> Cc: amd-gfx(a)lists.freedesktop.org Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Jérôme Glisse (2): gpu/radeon: use HMM mirror instead of mmu_notifier gpu/radeon: use HMM mirror for userptr buffer object. drivers/gpu/drm/radeon/radeon.h | 14 +- drivers/gpu/drm/radeon/radeon_gem.c | 16 +- drivers/gpu/drm/radeon/radeon_mn.c | 283 +++++++++++++++++++++------- drivers/gpu/drm/radeon/radeon_ttm.c | 129 ++----------- 4 files changed, 259 insertions(+), 183 deletions(-) -- 2.17.1

3 7

[PATCH v3] drm: Fix crtc color management when doing suspend/resume
by Alexandru Gheorghe 10 Sep '18

10 Sep '18

When doing suspend/resume drivers usually use the drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the state and then re-comitting it. The problem is that drm_crtc_state has a bool field called color_mgmt_changed, which mali-dp and other drivers uses it to detect if coefficients need to be reprogrammed, but that never happens because the saved state has color_mgmt_changed set to 0. Fix that by setting color_mgmt_changed to true in drm_atomic_helper_check_modeset when at least one of gamma_lut, degamma_lut, ctm is different between the new and the old crtc state. All current drivers that use color_mgmt_changed, either call directly drm_atomic_helper_check_modeset or they use drm_atomic_helper_check which calls drm_atomic_helper_check_modeset, so this makes unnecessary the setting of color_mgmt_changed in places where gamma_lut/degamma_lut/ctm are set in the new crtc_state. Changes since v2: - Instead of setting color_mgmt_changed in commit_duplicated_set just set it in check_modeset and clean up other place where it was set, suggested by Maarten Lankhorst. Changes since v3: - Rebased v2 on top of drm-misc-next and fix conflicts introduced by the move of drm_atomic_crtc_set_property in drm_atomic_uapi.c. Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe(a)arm.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 8 +++++++- drivers/gpu/drm/drm_atomic_uapi.c | 12 +++--------- drivers/gpu/drm/drm_fb_helper.c | 1 - 3 files changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 3cf1aa132778..53e60daa1bb6 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -612,6 +612,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, return -EINVAL; } + if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut || + new_crtc_state->ctm != old_crtc_state->ctm || + new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) { + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management changed\n", + crtc->base.id, crtc->name); + new_crtc_state->color_mgmt_changed = true; + } } ret = handle_conflicting_encoders(state, false); @@ -3948,7 +3955,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc, replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL); replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL); replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob); - crtc_state->color_mgmt_changed |= replaced; ret = drm_atomic_commit(state); diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 26690a664ec6..686da206427e 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -434,29 +434,23 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc, drm_property_blob_put(mode); return ret; } else if (property == config->degamma_lut_property) { - ret = drm_atomic_replace_property_blob_from_id(dev, + return drm_atomic_replace_property_blob_from_id(dev, &state->degamma_lut, val, -1, sizeof(struct drm_color_lut), &replaced); - state->color_mgmt_changed |= replaced; - return ret; } else if (property == config->ctm_property) { - ret = drm_atomic_replace_property_blob_from_id(dev, + return drm_atomic_replace_property_blob_from_id(dev, &state->ctm, val, sizeof(struct drm_color_ctm), -1, &replaced); - state->color_mgmt_changed |= replaced; - return ret; } else if (property == config->gamma_lut_property) { - ret = drm_atomic_replace_property_blob_from_id(dev, + return drm_atomic_replace_property_blob_from_id(dev, &state->gamma_lut, val, -1, sizeof(struct drm_color_lut), &replaced); - state->color_mgmt_changed |= replaced; - return ret; } else if (property == config->prop_out_fence_ptr) { s32 __user *fence_ptr = u64_to_user_ptr(val); diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 73cf10adebbf..a53e169e6824 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1442,7 +1442,6 @@ static int setcmap_atomic(struct fb_cmap *cmap, struct fb_info *info) replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL); replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, gamma_lut); - crtc_state->color_mgmt_changed |= replaced; } ret = drm_atomic_commit(state); -- 2.18.0

1 0

[PATCH xf86-video-amdgpu] Add checking color management properties
by Aaron Liu 10 Sep '18

10 Sep '18

Add gamma_lut/degamma_lut/ctm checking before pushing staged color management properties on the CRTC. If above object is NULL, return directly. Signed-off-by: Aaron Liu <aaron.liu(a)amd.com> --- src/drmmode_display.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index 68fca1b..006ae7c 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -1116,6 +1116,11 @@ static int drmmode_crtc_push_cm_prop(xf86CrtcPtr crtc, switch (cm_prop_index) { case CM_GAMMA_LUT: + if (!drmmode_crtc->gamma_lut) { + xf86DrvMsg(crtc->scrn->scrnIndex, X_WARNING, + "gamma_lut is NULL!\n"); + return BadRequest; + } /* Calculate the expected size of value in bytes */ expected_bytes = sizeof(struct drm_color_lut) * drmmode->gamma_lut_size; @@ -1154,11 +1159,21 @@ static int drmmode_crtc_push_cm_prop(xf86CrtcPtr crtc, } break; case CM_DEGAMMA_LUT: + if (!drmmode_crtc->degamma_lut) { + xf86DrvMsg(crtc->scrn->scrnIndex, X_WARNING, + "degamma_lut is NULL!\n"); + return BadRequest; + } expected_bytes = sizeof(struct drm_color_lut) * drmmode->degamma_lut_size; blob_data = drmmode_crtc->degamma_lut; break; case CM_CTM: + if (!drmmode_crtc->ctm) { + xf86DrvMsg(crtc->scrn->scrnIndex, X_WARNING, + "ctm is NULL!\n"); + return BadRequest; + } expected_bytes = sizeof(struct drm_color_ctm); blob_data = drmmode_crtc->ctm; break; -- 2.17.1

2 1

[Bug 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
by bugzilla-daemon＠freedesktop.org 10 Sep '18

10 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=107581 Bug ID: 107581 Summary: Graphics Not Rendered Due to Missing 4.5 COMPAT Profile Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: ben(a)xnode.org QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 141109 --> https://bugs.freedesktop.org/attachment.cgi?id=141109&action=edit Lack of rendered image Slightly obtuse issue as it's a game inside Wine. No Man's Sky used to work if you faked a compatibility profile. This no-longer works as, since the last game update, it seems they are actually using some of the COMPAT mode features. The result of this is that the game menu renders fine, but any of the "3D" graphics in the game are either missing or just render completely white. e.g. the starfield during loading should be various pinkish colours, but instead you just see a black screen. Once in-game, you should see the game world, but instead just have a (what seems to be non-refreshing) white screen. The game seems to be fine on Nvidia cards using their proprietary driver. Attached is an image of the issue to see specific what I'm referring to and a trace, from launch of the game, to a few minutes in game, to exiting the game. Generated with APITrace (I'll attach the trace in the next comment). -- You are receiving this mail because: You are the assignee for the bug.

1 21

[PATCH] drm: udl: Destroy framebuffer only if it was initialized
by Emil Lundmark 10 Sep '18

10 Sep '18

This fixes a NULL pointer dereference that can happen if the UDL driver is unloaded before the framebuffer is initialized. This can happen e.g. if the USB device is unplugged right after it was plugged in. Signed-off-by: Emil Lundmark <lndmrk(a)chromium.org> --- drivers/gpu/drm/udl/udl_fb.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c index 2ebdc6d5a76e..5754e37f741b 100644 --- a/drivers/gpu/drm/udl/udl_fb.c +++ b/drivers/gpu/drm/udl/udl_fb.c @@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev, { drm_fb_helper_unregister_fbi(&ufbdev->helper); drm_fb_helper_fini(&ufbdev->helper); - drm_framebuffer_unregister_private(&ufbdev->ufb.base); - drm_framebuffer_cleanup(&ufbdev->ufb.base); - drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base); + if (ufbdev->ufb.obj) { + drm_framebuffer_unregister_private(&ufbdev->ufb.base); + drm_framebuffer_cleanup(&ufbdev->ufb.base); + drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base); + } } int udl_fbdev_init(struct drm_device *dev) -- 2.17.0.484.g0c8726318c-goog

4 7

Re: Regression in drm: drm/fbdev doesn't initialize if set to triple buffer
by Neil Armstrong 10 Sep '18

10 Sep '18

Hi, Thanks for reporting this issue. On 08/09/2018 18:48, MOHAMMAD RASIM wrote: > Hi, > > I've an issue where the drm_meson driver doesn't work, it used to work in earlier 4.18 release and stopped working after about 4.18-rc3. > > My board is videostrong k2 pro (S905 SoC), I use the meson-gxbb-p201 device tree. > > on the latest 4.19 tree the board boots fine but the drm driver doesn't work, and spits the following error in dmesg > > [ 2.489825] meson-drm d0100000.vpu: Queued 3 outputs on vpu > [ 2.494685] meson-drm d0100000.vpu: Failed to create d0100000.vpu debugfs directory > [ 2.502051] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 2.508668] [drm] No driver support for vblank timestamp query. > [ 2.573756] meson-drm d0100000.vpu: bound c883a000.hdmi-tx (ops meson_dw_hdmi_ops) > [ 2.695917] meson-drm d0100000.vpu: [drm:drm_fb_helper_fbdev_setup] *ERROR* Failed to set fbdev configuration > [ 2.700310] meson-drm d0100000.vpu: master bind failed: -22 > [ 2.705747] meson-drm: probe of d0100000.vpu failed with error -22 > > Digging deeper into the problem revealed that the problem is related to the CONFIG_DRM_FBDEV_OVERALLOC option, If I set it to 100 or 200 it works fine and the drm driver works ( or by passing drm_kms_helper.drm_fbdev_overalloc=200 in the bootargs). The problem reappears when setting it to 300. > > Bisecting shows that the first bad commit that introduced this regression is this: 244007ecb6bb94fa4e9b9a969fa86f2ad86ec543 This commit points when the DRM driver has been switched to the generic fbdev emulation. Do you use the CONFIG_DRM_FBDEV_OVERALLOC to use the fbdev libMali ? if yes, it won't work anymore since the generic fbdev emulation does not export the fbdev smem physical address anymore. The solution is to switch to the GBM libMali and drop any fbdev legacy code. > > Another problem that I face and might be related is that the sometimes the boot get stuck on the following lines: > > [ 2.501539] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 2.508158] [drm] No driver support for vblank timestamp query. > > This problem is random and can't always reproduced, sometimes it takes a few reboots to get the board to boot pass those lines. Weird, can you elaborate on you complete linux version, patches and HW ? > > Regards > Neil

1 0

[PATCH v2 0/4] Add support for Arm Framebuffer Compression(AFBC)
by Ayan Kumar Halder 10 Sep '18

10 Sep '18

In the current series of patches, we are trying to add support for AFBC modifiers in malidp. AFBC modifiers adds some constraints to framebuffer size, alignment, pitch, formats, etc. Here we are trying to add support for one combination of AFBC modifier ie AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE | AFBC_FORMAT_MOD_YTR. In future, we intend to add support for more combination of AFBC modifiers. Currently, we are trying to enable a basic support of AFBC in malidp. Changes from v2: - Added ack by Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> for patch 1. However, this has been kept in this series in order to help reviewers review the other patches (which are related to patch 1) - For patches 2 and 4, replaced DRM_ERROR() with DRM_DEBUG_KMS() - For patch 3, reworked malidp_de_set_plane_afbc() so as to consolidate all afbc specific register configuration in this. Ayan Kumar Halder (4): drm/arm/malidp: Add modifier definitions for describing Arm Framebuffer Compression (AFBC). drm/arm/malidp: Implemented the size validation for AFBC framebuffers drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART drivers/gpu/drm/arm/malidp_drv.c | 129 +++++++++++++++++++++++++++++++++++- drivers/gpu/drm/arm/malidp_hw.c | 27 +++++--- drivers/gpu/drm/arm/malidp_hw.h | 7 ++ drivers/gpu/drm/arm/malidp_planes.c | 129 +++++++++++++++++++++++++++++++++--- drivers/gpu/drm/arm/malidp_regs.h | 20 ++++++ include/uapi/drm/drm_fourcc.h | 83 +++++++++++++++++++++++ 6 files changed, 373 insertions(+), 22 deletions(-) -- 2.7.4

5 10

[Bug 107876] GPU lockup with Radeon HD 7850 in 18.1.6 driver
by bugzilla-daemon＠freedesktop.org 10 Sep '18

10 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=107876 Michel Dänzer <michel(a)daenzer.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Michel Dänzer <michel(a)daenzer.net> --- *** This bug has been marked as a duplicate of bug 105381 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] staging/vboxvideo: Replace ttm_bo_unref with ttm_bo_put
by Thomas Zimmermann 10 Sep '18

10 Sep '18

The function ttm_bo_put releases a reference to a TTM buffer object. The function's name is more aligned to the Linux kernel convention of naming ref-counting function _get and _put. A call to ttm_bo_unref takes the address of the TTM BO object's pointer and clears the pointer's value to NULL. This is not necessary in most cases and sometimes even worked around by the calling code. A call to ttm_bo_put only releases the reference without clearing the pointer. The current behaviour of cleaning the pointer is kept in the calling code, but should be removed if not required in a later patch. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> --- drivers/staging/vboxvideo/vbox_main.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_main.c b/drivers/staging/vboxvideo/vbox_main.c index 429f6a453619..b6cff31903b3 100644 --- a/drivers/staging/vboxvideo/vbox_main.c +++ b/drivers/staging/vboxvideo/vbox_main.c @@ -490,9 +490,8 @@ static void vbox_bo_unref(struct vbox_bo **bo) return; tbo = &((*bo)->bo); - ttm_bo_unref(&tbo); - if (!tbo) - *bo = NULL; + ttm_bo_put(tbo); + *bo = NULL; } void vbox_gem_free_object(struct drm_gem_object *obj) -- 2.18.0

1 0

[Bug 107784] [AMD tahiti XT] displayport broken
by bugzilla-daemon＠freedesktop.org 10 Sep '18

10 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=107784 Bug ID: 107784 Summary: [AMD tahiti XT] displayport broken Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: highest Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: sylvain.bertrand(a)gmail.com linux 4.19-rc1+ branch: amd-staging-drm-next commit:d0a96214993c5dad9c2a54b888209f0f5cafd060 amdgpu is unable to program my displayport monitor anymore (was working in 4.18-rc1+) see the error messages in the kernel log -- You are receiving this mail because: You are the assignee for the bug.

2 34

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2018