Re: [PATCH] staging: vboxvideo: adapt to new TTM interface
Am 24.11.2017 um 11:31 schrieb Greg KH: On Fri, Nov 24, 2017 at 11:29:27AM +0100, Christian König wrote: I missed this driver because it is in the staging area. What does this changelog text mean??? Sorry for the confusion, the patch was originally part of a larger series. Just send it out again with an updated commit message. Signed-off-by: Christian KönigReviewed-by: Hans de Goede --- drivers/staging/vboxvideo/vbox_ttm.c | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) Please provide something that makes sense when reading the changelog text on its own. Done, but please note that I'm not sure if the interface this breaks has already reached any of the relevant upstream repositories. I just added you to the list of recipients because Hans suggested to do so. Regards, Christian. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/15] drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangle
On Thu, Nov 23, 2017 at 09:04:51PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > Note that this replaces crtc_state->adjusted_mode usage with > crtc_state->mode. The latter is the correct choice since that's the > mode the user provided and it matches the plane crtc coordinates > the user also provided. > > Once everyone agrees on this we can move the clip handling into > drm_atomic_helper_check_plane_state(). > > Cc: Laurent Pinchart > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: Mali DP Maintainers > Signed-off-by: Ville Syrjälä Acked-by: Liviu Dudau Please let me know if you need me to pull this patch into the mali-dp tree. Best regards, Liviu > --- > drivers/gpu/drm/arm/malidp_planes.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > b/drivers/gpu/drm/arm/malidp_planes.c > index 72a07950167e..2f6d608d6eaf 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -148,8 +148,10 @@ static int malidp_se_check_scaling(struct malidp_plane > *mp, > if (!crtc_state) > return -EINVAL; > > - clip.x2 = crtc_state->adjusted_mode.hdisplay; > - clip.y2 = crtc_state->adjusted_mode.vdisplay; > + if (crtc_state->enable) > + drm_mode_get_hv_timing(_state->mode, > +, ); > + > ret = drm_atomic_helper_check_plane_state(state, crtc_state, , > 0, INT_MAX, true, true); > if (ret) > -- > 2.13.6 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: adapt to new TTM interface
Am 24.11.2017 um 11:37 schrieb Greg KH: On Fri, Nov 24, 2017 at 11:32:59AM +0100, Christian König wrote: Fixes interface changes done in the following commits: drm/ttm: add operation ctx to ttm_bo_validate v2 drm/ttm: add context to driver move callback as well Any hints on the git commit ids in Linus's tree? Those haven't arrived in Linus tree yet. And does this mean the driver's build is now broken? Yes, it broke the build. Sorry that was my fault, didn't had this staging driver activated in the config nor noticed that there is an user of ttm outside the drm directory. Should this go through the staging tree, or is it to go through the drm tree? The DRM tree I think. We should probably squash this patch into the original change which broke the driver in the DRM tree. Regards, Christian. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REBASE 2/5] drm: Handle aspect ratio in modeset paths
Hi Ville, Thanks for the suggestions. Please find my response inline On 11/21/2017 10:41 PM, Ville Syrjälä wrote: On Fri, Nov 17, 2017 at 03:00:29PM +0530, Shashank Sharma wrote: From: Ankit NautiyalIf the user mode does not support aspect-ratio, and requests for a modeset with aspect ratio flags, then the flag bits reprsenting aspect ratio must be ignored. Rejected, not ignored. Rejection should happen when converting the umode to mode. And filtering should happen in getcrtc and getblob. The way you're currently doing things will corrupt the current state, which is not good. Agreed. The filtering is being done in getcrtc but getblob was missing. Will add the changes in getblob and send the new patch. Regards, Ankit Similarly, if user space doesn't set the aspect ratio client cap, while preparing a usermode, the aspect-ratio info must not be given into it. This patch: 1. adds a new bit field aspect_ratio_allowed in drm_atomic_state, which is set only if the aspect-ratio is supported by the user. 2. discards the aspect-ratio info from the user mode while preparing kernel mode structure, during modeset, if the user does not support aspect ratio. 3. avoids setting the aspect-ratio info in user-mode, while converting user-mode from the kernel-mode. Cc: Ville Syrjala Cc: Shashank Sharma Cc: Jose Abreu Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/drm_atomic.c | 40 +--- drivers/gpu/drm/drm_crtc.c | 19 +++ include/drm/drm_atomic.h | 2 ++ 3 files changed, 54 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 37445d5..b9743af 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -338,18 +338,30 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state, state->mode_blob = NULL; if (mode) { - drm_mode_convert_to_umode(, mode); + /* +* If the user has not asked for aspect ratio support, +* take a copy of the 'mode' and set the aspect ratio as +* None. This copy is used to prepare the user-mode with no +* aspect-ratio info. +*/ + struct drm_display_mode ar_mode; + struct drm_atomic_state *atomic_state = state->state; + + drm_mode_copy(_mode, mode); + if (atomic_state && !atomic_state->allow_aspect_ratio) + ar_mode.picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; + drm_mode_convert_to_umode(, _mode); state->mode_blob = drm_property_create_blob(state->crtc->dev, -sizeof(umode), -); +sizeof(umode), +); if (IS_ERR(state->mode_blob)) return PTR_ERR(state->mode_blob); - drm_mode_copy(>mode, mode); + drm_mode_copy(>mode, _mode); state->enable = true; DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n", -mode->name, state); +ar_mode.name, state); } else { memset(>mode, 0, sizeof(state->mode)); state->enable = false; @@ -386,10 +398,23 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state, memset(>mode, 0, sizeof(state->mode)); if (blob) { + struct drm_mode_modeinfo *ar_umode; + struct drm_atomic_state *atomic_state; + + /* +* If the user-space does not ask for aspect-ratio +* the aspect ratio bits in the drmModeModeinfo from user, +* does not mean anything. Therefore these bits must be +* discarded. +*/ + ar_umode = (struct drm_mode_modeinfo *) blob->data; + atomic_state = state->state; + if (atomic_state && !atomic_state->allow_aspect_ratio) + ar_umode->flags &= (~DRM_MODE_FLAG_PIC_AR_MASK); if (blob->length != sizeof(struct drm_mode_modeinfo) || drm_mode_convert_umode(>mode, - (const struct drm_mode_modeinfo *) - blob->data)) + (const struct drm_mode_modeinfo *) + ar_umode)) return -EINVAL; state->mode_blob = drm_property_blob_get(blob); @@ -2229,6 +2254,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
[PATCH] staging: vboxvideo: adapt to new TTM interface
I missed this driver because it is in the staging area. Signed-off-by: Christian KönigReviewed-by: Hans de Goede --- drivers/staging/vboxvideo/vbox_ttm.c | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_ttm.c b/drivers/staging/vboxvideo/vbox_ttm.c index 4eb410a2a1a8..231c89e0699c 100644 --- a/drivers/staging/vboxvideo/vbox_ttm.c +++ b/drivers/staging/vboxvideo/vbox_ttm.c @@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev, { } -static int vbox_bo_move(struct ttm_buffer_object *bo, - bool evict, bool interruptible, - bool no_wait_gpu, struct ttm_mem_reg *new_mem) -{ - return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem); -} - static void vbox_ttm_backend_destroy(struct ttm_tt *tt) { ttm_tt_fini(tt); @@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = { .init_mem_type = vbox_bo_init_mem_type, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = vbox_bo_evict_flags, - .move = vbox_bo_move, .verify_access = vbox_bo_verify_access, .io_mem_reserve = _ttm_io_mem_reserve, .io_mem_free = _ttm_io_mem_free, @@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo) int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (bo->pin_count) { @@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(>bo, >placement, false, false); + ret = ttm_bo_validate(>bo, >placement, ); if (ret) return ret; @@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) int vbox_bo_unpin(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(>bo, >placement, false, false); + ret = ttm_bo_validate(>bo, >placement, ); if (ret) return ret; @@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) */ int vbox_bo_push_sysram(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(>bo, >placement, false, false); + ret = ttm_bo_validate(>bo, >placement, ); if (ret) { DRM_ERROR("pushing to VRAM failed\n"); return ret; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/15] drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangle
On Thu, Nov 23, 2017 at 09:04:50PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > Note that this replaces crtc_state->adjusted_mode usage with > crtc_state->mode. The latter is the correct choice since that's the > mode the user provided and it matches the plane crtc coordinates > the user also provided. > > Once everyone agrees on this we can move the clip handling into > drm_atomic_helper_check_plane_state(). > > Cc: Laurent Pinchart > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: Mali DP Maintainers > Signed-off-by: Ville Syrjälä Acked-by: Liviu Dudau Please let me know if you need me to pull this patch into the HDLCD tree. Best regards, Liviu > --- > drivers/gpu/drm/arm/hdlcd_crtc.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c > index 63511a3bbf6c..fa852fc1c9e6 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -249,8 +249,9 @@ static int hdlcd_plane_atomic_check(struct drm_plane > *plane, > return -EINVAL; > } > > - clip.x2 = crtc_state->adjusted_mode.hdisplay; > - clip.y2 = crtc_state->adjusted_mode.vdisplay; > + if (crtc_state->enable) > + drm_mode_get_hv_timing(_state->mode, > +, ); > > return drm_atomic_helper_check_plane_state(state, crtc_state, , > DRM_PLANE_HELPER_NO_SCALING, > -- > 2.13.6 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: adapt to new TTM interface
On Fri, Nov 24, 2017 at 11:29:27AM +0100, Christian König wrote: > I missed this driver because it is in the staging area. What does this changelog text mean??? > Signed-off-by: Christian König> Reviewed-by: Hans de Goede > --- > drivers/staging/vboxvideo/vbox_ttm.c | 17 ++--- > 1 file changed, 6 insertions(+), 11 deletions(-) Please provide something that makes sense when reading the changelog text on its own. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: adapt to new TTM interface
On Fri, Nov 24, 2017 at 11:32:59AM +0100, Christian König wrote: > Fixes interface changes done in the following commits: > drm/ttm: add operation ctx to ttm_bo_validate v2 > drm/ttm: add context to driver move callback as well Any hints on the git commit ids in Linus's tree? And does this mean the driver's build is now broken? Should this go through the staging tree, or is it to go through the drm tree? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > From: Ville SyrjäläHi Ville, > > Move the plane clip rectangle handling into > drm_atomic_helper_check_plane_state(). Drivers no longer > have to worry about such mundane details. This is quite an important patch and I dare say the essence of your series, right? Yet very few people got Cc-ed on it (1 AFAICT) and it touches quite a few drivers. May I respectfully suggest that you review your patch sending process? You have Cc-ed me only on patches 3 and 4 and I could easy asssume that those were all the changes you have made to the driver, which is obviously not the case here. I tend to err on the side of verbosity and include everyone touched by a patch in a series into all the patches of that series. Is by no mean the best approach, but is one way I avoid situations like this. Best regards, Liviu > > Cc: Laurent Pinchart > Cc: Daniel Vetter > Suggested-by: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +-- > drivers/gpu/drm/arm/malidp_planes.c | 7 +-- > drivers/gpu/drm/armada/armada_overlay.c | 6 +- > drivers/gpu/drm/drm_atomic_helper.c | 12 +++- > drivers/gpu/drm/drm_plane_helper.c | 11 +++ > drivers/gpu/drm/drm_simple_kms_helper.c | 6 -- > drivers/gpu/drm/i915/intel_display.c| 12 > drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +-- > drivers/gpu/drm/meson/meson_plane.c | 7 +-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ > drivers/gpu/drm/nouveau/nv50_display.c | 12 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-- > drivers/gpu/drm/tegra/dc.c | 7 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +-- > drivers/gpu/drm/zte/zx_plane.c | 13 + > include/drm/drm_atomic_helper.h | 1 - > include/drm/drm_plane_helper.h | 1 - > 18 files changed, 22 insertions(+), 122 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c > index fa852fc1c9e6..93c503b754ba 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs > hdlcd_crtc_helper_funcs = { > static int hdlcd_plane_atomic_check(struct drm_plane *plane, > struct drm_plane_state *state) > { > - struct drm_rect clip = { 0 }; > struct drm_crtc_state *crtc_state; > u32 src_h = state->src_h >> 16; > > @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane > *plane, > return -EINVAL; > } > > - if (crtc_state->enable) > - drm_mode_get_hv_timing(_state->mode, > -, ); > - > - return drm_atomic_helper_check_plane_state(state, crtc_state, , > + return drm_atomic_helper_check_plane_state(state, crtc_state, > DRM_PLANE_HELPER_NO_SCALING, > DRM_PLANE_HELPER_NO_SCALING, > false, true); > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > b/drivers/gpu/drm/arm/malidp_planes.c > index 2f6d608d6eaf..e630c0218aaf 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane > *mp, > struct drm_crtc_state *crtc_state = > drm_atomic_get_existing_crtc_state(state->state, state->crtc); > struct malidp_crtc_state *mc; > - struct drm_rect clip = { 0 }; > u32 src_w, src_h; > int ret; > > if (!crtc_state) > return -EINVAL; > > - if (crtc_state->enable) > - drm_mode_get_hv_timing(_state->mode, > -, ); > - > - ret = drm_atomic_helper_check_plane_state(state, crtc_state, , > + ret = drm_atomic_helper_check_plane_state(state, crtc_state, > 0, INT_MAX, true, true); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index b411b608821a..564bd63a5f6a 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++ b/drivers/gpu/drm/armada/armada_overlay.c > @@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct > drm_crtc *crtc, > .x2 = crtc_x + crtc_w, > .y2 = crtc_y + crtc_h, > }; > - const struct drm_rect clip = { > - .x2 =
[PATCH] staging: vboxvideo: adapt to new TTM interface
Fixes interface changes done in the following commits: drm/ttm: add operation ctx to ttm_bo_validate v2 drm/ttm: add context to driver move callback as well I missed this driver because it is in the staging area. Signed-off-by: Christian KönigReviewed-by: Hans de Goede --- drivers/staging/vboxvideo/vbox_ttm.c | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_ttm.c b/drivers/staging/vboxvideo/vbox_ttm.c index 4eb410a2a1a8..231c89e0699c 100644 --- a/drivers/staging/vboxvideo/vbox_ttm.c +++ b/drivers/staging/vboxvideo/vbox_ttm.c @@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev, { } -static int vbox_bo_move(struct ttm_buffer_object *bo, - bool evict, bool interruptible, - bool no_wait_gpu, struct ttm_mem_reg *new_mem) -{ - return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem); -} - static void vbox_ttm_backend_destroy(struct ttm_tt *tt) { ttm_tt_fini(tt); @@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = { .init_mem_type = vbox_bo_init_mem_type, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = vbox_bo_evict_flags, - .move = vbox_bo_move, .verify_access = vbox_bo_verify_access, .io_mem_reserve = _ttm_io_mem_reserve, .io_mem_free = _ttm_io_mem_free, @@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo) int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (bo->pin_count) { @@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(>bo, >placement, false, false); + ret = ttm_bo_validate(>bo, >placement, ); if (ret) return ret; @@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) int vbox_bo_unpin(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(>bo, >placement, false, false); + ret = ttm_bo_validate(>bo, >placement, ); if (ret) return ret; @@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) */ int vbox_bo_push_sysram(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(>bo, >placement, false, false); + ret = ttm_bo_validate(>bo, >placement, ); if (ret) { DRM_ERROR("pushing to VRAM failed\n"); return ret; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103850] "Quern" game crashes on start-up
https://bugs.freedesktop.org/show_bug.cgi?id=103850 --- Comment #6 from Michel Dänzer--- The valgrind output for Quern shows writes to freed memory, because the game makes libX11 calls using a display handle that it had already closed. That's a bug in the game (or maybe in a library it links statically), which could explain the crash. I don't see any obvious issue in the valgrind output for Unturned either though. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: bridge: synopsys/dw-hdmi: Enable cec clock
Hi, On 11/20/2017 06:00 PM, Hans Verkuil wrote: I didn't see this merged for 4.15, is it too late to include this? All other changes needed to get CEC to work on rk3288 and rk3399 are all merged. Sorry for the late reply. I was out last week. Dave recently sent the second pull request for 4.15, so I think it would be hard to get it in the merge window now. We could target it for the 4.15-rcs since it is preventing the feature from working. Is it possible to rephrase the commit message a bit so that it's clear that we need it for CEC to work? Thanks, Archit Regards, Hans On 10/26/2017 08:19 PM, Pierre-Hugues Husson wrote: The documentation already mentions "cec" optional clock, but currently the driver doesn't enable it. Changes: v3: - Drop useless braces v2: - Separate ENOENT errors from others - Propagate other errors (especially -EPROBE_DEFER) Signed-off-by: Pierre-Hugues Husson--- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 + 1 file changed, 25 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index bf14214fa464..d82b9747a979 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -138,6 +138,7 @@ struct dw_hdmi { struct device *dev; struct clk *isfr_clk; struct clk *iahb_clk; + struct clk *cec_clk; struct dw_hdmi_i2c *i2c; struct hdmi_data_info hdmi_data; @@ -2382,6 +2383,26 @@ __dw_hdmi_probe(struct platform_device *pdev, goto err_isfr; } + hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec"); + if (PTR_ERR(hdmi->cec_clk) == -ENOENT) { + hdmi->cec_clk = NULL; + } else if (IS_ERR(hdmi->cec_clk)) { + ret = PTR_ERR(hdmi->cec_clk); + if (ret != -EPROBE_DEFER) + dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n", + ret); + + hdmi->cec_clk = NULL; + goto err_iahb; + } else { + ret = clk_prepare_enable(hdmi->cec_clk); + if (ret) { + dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n", + ret); + goto err_iahb; + } + } + /* Product and revision IDs */ hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8) | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0); @@ -2518,6 +2539,8 @@ __dw_hdmi_probe(struct platform_device *pdev, cec_notifier_put(hdmi->cec_notifier); clk_disable_unprepare(hdmi->iahb_clk); + if (hdmi->cec_clk) + clk_disable_unprepare(hdmi->cec_clk); err_isfr: clk_disable_unprepare(hdmi->isfr_clk); err_res: @@ -2541,6 +2564,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi) clk_disable_unprepare(hdmi->iahb_clk); clk_disable_unprepare(hdmi->isfr_clk); + if (hdmi->cec_clk) + clk_disable_unprepare(hdmi->cec_clk); if (hdmi->i2c) i2c_del_adapter(>i2c->adap); -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103887] OpenCL segfault on RX550 (Lexa)
https://bugs.freedesktop.org/show_bug.cgi?id=103887 Bug ID: 103887 Summary: OpenCL segfault on RX550 (Lexa) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: luka.kari...@gmail.com Hello. Support for RX550 (Lexa) seem to be missing for the amdgpu-pro driver i did try amdgpu-pro from 17.10 - 17.40. clinfo shows no devices aviabile and if i force an app to use the opencl lib from amdgpupro the app segfaults... Release notes from the drivers clearly states Lexa supports OpenCL with pro drivers -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REBASE 3/5] drm: Expose modes with aspect ratio, only if requested
Regards Shashank On 11/21/2017 10:41 PM, Ville Syrjälä wrote: On Fri, Nov 17, 2017 at 03:00:30PM +0530, Shashank Sharma wrote: From: aknautiyWe parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regadless of if user space requested this information or not. This patch prunes the modes with aspect-ratio information, from a connector's modelist, if the user-space has not set the aspect ratio DRM client cap. Cc: Ville Syrjala Cc: Shashank Sharma Cc: Jose Abreu Signed-off-by: aknautiy --- drivers/gpu/drm/drm_connector.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 704fc89..a246bb5 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1285,6 +1285,13 @@ static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode, */ if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode)) return false; + /* +* If user-space hasn't configured the driver to expose the modes +* with aspect-ratio, don't expose them. +*/ + if (!file_priv->aspect_ratio_allowed && + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) + return false; I don't think we can just blindly drop the modes. We would have to expose them with the aspect ratio cleared. That could lead to duplicates, but I'm thinking that shouldn't be a real problem for userspace. Having to filteri out the duplicates would certainly complicate things a bit. Yes, Agree. Even I was thinking that the right way should be to: - add a drm_mode_equal_no_aspect function (like drm_mode_equal_no_clock_no_stereo). - clear the aspect ratio information from the mode, when not asked for. - check the sorted connector->modes list for duplicates for this mode, using above function. - if mode exists, remove it from the list - if not, keep it in the list Sounds like a plan ? - Shashank return true; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add basic support for emtrion emCON-MX6 modules
The following patch-series adds support for emtrion's emCON-MX6 modules with all their dependencies. The focus is based on the emtion standard developer-kit configuration. It includes a new vendor-prefix, an new simple-panel type, a small modification of the imx6dl.dtsi, as well as modifications of the common imx_v6_v8_defconfig. And finally the board devicetrees themselves. emtrion GmbH Kreativpark - Alter Schlachthof 45 76131 Karlsruhe GERMANY http://www.emtrion.de ___ Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.
All recent emtrion modules based on i.mx6 make use of the DA0963. Therefore enable it with the following defaults: - CONFIG_MFD_DA9063=y - CONFIG_REGULATOR_DA9063=y - CONFIG_DA9063_WATCHDOG=m - CONFIG_RTC_DRV_DA9063=m MFD and REGULATOR are built-in to have it at Kernel boot-time. The WATCHDOG and RTC are optional and could be loaded from userspace. Signed-off-by: Jan Tuerk--- arch/arm/configs/imx_v6_v7_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 0d4494922561..09cd8048b0c1 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -215,8 +215,10 @@ CONFIG_THERMAL_WRITABLE_TRIPS=y CONFIG_CPU_THERMAL=y CONFIG_IMX_THERMAL=y CONFIG_WATCHDOG=y +CONFIG_DA9063_WATCHDOG=m CONFIG_IMX2_WDT=y CONFIG_MFD_DA9052_I2C=y +CONFIG_MFD_DA9063=y CONFIG_MFD_MC13XXX_SPI=y CONFIG_MFD_MC13XXX_I2C=y CONFIG_MFD_STMPE=y @@ -224,6 +226,7 @@ CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_ANATOP=y CONFIG_REGULATOR_DA9052=y +CONFIG_REGULATOR_DA9063=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MC13783=y CONFIG_REGULATOR_MC13892=y @@ -349,6 +352,7 @@ CONFIG_RTC_DRV_PCF8563=y CONFIG_RTC_DRV_M41T80=y CONFIG_RTC_DRV_MC13XXX=y CONFIG_RTC_DRV_MXC=y +CONFIG_RTC_DRV_DA9063=m CONFIG_RTC_DRV_SNVS=y CONFIG_DMADEVICES=y CONFIG_FSL_EDMA=y -- 2.11.0 emtrion GmbH Kreativpark - Alter Schlachthof 45 76131 Karlsruhe GERMANY http://www.emtrion.de ___ Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in TTM driver w/Linus' master
On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbottwrote: Hi, Fedora QA testing reported a panic when booting up VMs using qmeu vga drivers (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ) [ 30.108507] [ cut here ] [ 30.108920] kernel BUG at ./include/linux/gfp.h:408! [ 30.109356] invalid opcode: [#1] SMP [ 30.109700] Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc virtio_net [ 30.115605] virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop [ 30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 4.15.0-0.rc0.git6.1.fc28.x86_64 #1 [ 30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 30.118866] task: 923a77e03380 task.stack: a78182228000 [ 30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430 [ 30.119810] RSP: :a7818222bba8 EFLAGS: 00010202 [ 30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006 [ 30.120840] RDX: RSI: 0009 RDI: [ 30.121443] RBP: 923a760d6000 R08: R09: 0006 [ 30.122039] R10: 0040 R11: 0300 R12: 923a729273c0 [ 30.122629] R13: R14: R15: 923a7483d400 [ 30.123223] FS: 7fe48da7dac0() GS:923a7cc0() knlGS: [ 30.123896] CS: 0010 DS: ES: CR0: 80050033 [ 30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0 [ 30.124968] Call Trace: [ 30.125186] ttm_pool_populate+0x19b/0x400 [ttm] [ 30.125578] ttm_bo_vm_fault+0x325/0x570 [ttm] [ 30.125964] __do_fault+0x19/0x11e [ 30.126255] __handle_mm_fault+0xcd3/0x1260 [ 30.126609] handle_mm_fault+0x14c/0x310 [ 30.126947] __do_page_fault+0x28c/0x530 [ 30.127282] do_page_fault+0x32/0x270 [ 30.127593] async_page_fault+0x22/0x30 [ 30.127922] RIP: 0033:0x7fe48aae39a8 [ 30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206 [ 30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040 [ 30.129259] RDX: 0030 RSI: RDI: 7fe457b73000 [ 30.129855] RBP: 0300 R08: 000c R09: 0001 [ 30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0 [ 30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400 [ 30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c [ 30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8 [ 30.133836] ---[ end trace d4f1deb60784f40a ]--- This is based off of Linus' master branch at c8a0739b185d11d6e2ca7ad9f5835841d1cfc765 Configs are at https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 Looks like a TTM regression due to: 0284f1ead87463bc17cf5e81a24fc65c052486f3 drm/ttm: add transparent huge page support for cached allocations v2 If the driver requests dma32 pages, we can end up trying to alloc huge dma32 pages which triggers the oops. The bochs driver always requests dma32 here. I'll send a rough patch once I boot it. Dave. Hi Dave, fyi only: It looks like this is not the only regression in this cycle with ttm, novueau seems to suffer as well [1]. Greetings, Tobias [1]: [ 404.918139] [ cut here ] [ 404.918147] kernel BUG at mm/shmem.c:4334! [ 404.918152] invalid opcode: [#2] PREEMPT SMP [ 404.918157] Modules linked in: rfcomm af_packet bnep uvcvideo videobuf2_vmalloc videobuf2_memops rtsx_usb_ms videobuf2_v4l2 memstick videodev videobuf2_core btusb btrtl btbcm arc4 msr snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 nls_cp437 hid_multitouch vfat fat iTCO_wdt iTCO_vendor_support intel_rapl x86_pkg_temp_thermal intel_powerclamp ath10k_pci
Re: [PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH
Am 23.11.2017 um 13:55 schrieb Jan Tuerk: > emtrion is a system integrator and manufacturer of embedded systems. > > Website: https://www.emtrion.de > > Signed-off-by: Jan Tuerk> --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Andreas Färber Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: bridge: synopsys/dw-hdmi: Enable cec clock
On 11/24/2017 09:04 AM, Archit Taneja wrote: > Hi, > > On 11/20/2017 06:00 PM, Hans Verkuil wrote: >> I didn't see this merged for 4.15, is it too late to include this? >> All other changes needed to get CEC to work on rk3288 and rk3399 are all >> merged. > > Sorry for the late reply. I was out last week. > > Dave recently sent the second pull request for 4.15, so I think it would be > hard to get it > in the merge window now. We could target it for the 4.15-rcs since it is > preventing the > feature from working. Is it possible to rephrase the commit message a bit so > that it's clear > that we need it for CEC to work? While it is not my patch I would propose something like this: "Support the "cec" optional clock. The documentation already mentions "cec" optional clock and it is used by several boards, but currently the driver doesn't enable it, thus preventing cec from working on those boards. And even worse: a /dev/cecX device will appear for those boards, but it won't be functioning without configuring this clock." I hadn't realized that last sentence until I started thinking about it, but this patch is really needed. Regards, Hans > > Thanks, > Archit > >> >> Regards, >> >> Hans >> >> On 10/26/2017 08:19 PM, Pierre-Hugues Husson wrote: >>> The documentation already mentions "cec" optional clock, but >>> currently the driver doesn't enable it. >>> >>> Changes: >>> v3: >>> - Drop useless braces >>> >>> v2: >>> - Separate ENOENT errors from others >>> - Propagate other errors (especially -EPROBE_DEFER) >>> >>> Signed-off-by: Pierre-Hugues Husson>>> --- >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 + >>> 1 file changed, 25 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> index bf14214fa464..d82b9747a979 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> @@ -138,6 +138,7 @@ struct dw_hdmi { >>> struct device *dev; >>> struct clk *isfr_clk; >>> struct clk *iahb_clk; >>> + struct clk *cec_clk; >>> struct dw_hdmi_i2c *i2c; >>> >>> struct hdmi_data_info hdmi_data; >>> @@ -2382,6 +2383,26 @@ __dw_hdmi_probe(struct platform_device *pdev, >>> goto err_isfr; >>> } >>> >>> + hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec"); >>> + if (PTR_ERR(hdmi->cec_clk) == -ENOENT) { >>> + hdmi->cec_clk = NULL; >>> + } else if (IS_ERR(hdmi->cec_clk)) { >>> + ret = PTR_ERR(hdmi->cec_clk); >>> + if (ret != -EPROBE_DEFER) >>> + dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n", >>> + ret); >>> + >>> + hdmi->cec_clk = NULL; >>> + goto err_iahb; >>> + } else { >>> + ret = clk_prepare_enable(hdmi->cec_clk); >>> + if (ret) { >>> + dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n", >>> + ret); >>> + goto err_iahb; >>> + } >>> + } >>> + >>> /* Product and revision IDs */ >>> hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8) >>> | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0); >>> @@ -2518,6 +2539,8 @@ __dw_hdmi_probe(struct platform_device *pdev, >>> cec_notifier_put(hdmi->cec_notifier); >>> >>> clk_disable_unprepare(hdmi->iahb_clk); >>> + if (hdmi->cec_clk) >>> + clk_disable_unprepare(hdmi->cec_clk); >>> err_isfr: >>> clk_disable_unprepare(hdmi->isfr_clk); >>> err_res: >>> @@ -2541,6 +2564,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi) >>> >>> clk_disable_unprepare(hdmi->iahb_clk); >>> clk_disable_unprepare(hdmi->isfr_clk); >>> + if (hdmi->cec_clk) >>> + clk_disable_unprepare(hdmi->cec_clk); >>> >>> if (hdmi->i2c) >>> i2c_del_adapter(>i2c->adap); >>> >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
On 11/23/2017 03:11 AM, Christian König wrote: Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: On 11/22/2017 05:09 AM, Christian König wrote: Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: On 11/21/2017 08:34 AM, Christian König wrote: Hi Boris, attached are two patches. The first one is a trivial fix for the infinite loop issue, it now correctly aborts the fixup when it can't find address space for the root window. The second is a workaround for your board. It simply checks if there is exactly one Processor Function to apply this fix on. Both are based on linus current master branch. Please test if they fix your issue. Yes, they do fix it but that's because the feature is disabled. Do you know what the actual problem was (on Xen)? I still haven't understood what you actually did with Xen. When you used PCI pass through with those devices then you have made a major configuration error. When the problem happened on dom0 then the explanation is most likely that some PCI device ended up in the configured space, but the routing was only setup correctly on one CPU socket. The problem is that dom0 can be (and was in my case() booted with less than full physical memory and so the "rest" of the host memory is not necessarily reflected in iomem. Your patch then tried to configure that memory for MMIO and the system hang. And so my guess is that this patch will break dom0 on a single-socket system as well. Oh, thanks! I've thought about that possibility before, but wasn't able to find a system which actually does that. May I ask why the rest of the memory isn't reported to the OS? That memory doesn't belong to the OS (dom0), it is owned by the hypervisor. Sounds like I can't trust Linux resource management and probably need to read the DRAM config to figure things out after all. My question is whether what you are trying to do should ever be done for a guest at all (any guest, not necessarily Xen). The issue is probably that I don't know enough about Xen: What exactly is dom0? My understanding was that dom0 is the hypervisor, but that seems to be incorrect. The issue is that under no circumstances *EVER* a virtualized guest should have access to the PCI devices marked as "Processor Function" on AMD platforms. Otherwise it is trivial to break out of the virtualization. When dom0 is something like the system domain with all hardware access then the approach seems legitimate, but then the hypervisor should report the stolen memory to the OS using the e820 table. When the hypervisor doesn't do that and the Linux kernel isn't aware that there is memory at a given location mapping PCI space there will obviously crash the hypervisor. Possible solutions as far as I can see are either disabling this feature when we detect that we are a Xen dom0, scanning the DRAM settings to update Linux resource handling or fixing Xen to report stolen memory to the dom0 OS as reserved. Opinions? You are right, these functions are not exposed to a regular guest. I think for dom0 (which is a special Xen guest, with additional privileges) we may be able to add a reserved e820 region for host memory that is not assigned to dom0. Let me try it on Monday (I am out until then). -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] mfd: mtk-mmsys: Add mmsys driver
On 11/23/2017 10:04 AM, CK Hu wrote: >> +static const struct of_device_id of_match_mmsys[] = { >> +{ .compatible = "mediatek,mt2701-mmsys", > > Because this driver replace the original "mediatek,mt2701-mmsys" driver, > could you modify the binding document of "mediatek,mt2701-mmsys" [1]? > > [1] > https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt > Well we are actually no replacing the compatible but keeping it. But yes, the documentation should be updated. Apart right now we have the definition twice. The other location is here: Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/mediatek: mt2701: switch to mfd probing.
On 11/23/2017 06:48 AM, CK Hu wrote: > Hi, Matthias: > > On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: >> With the mtk-mmsys MFD device in place, we switch the probing for >> mt2701 from device-tree to mfd. >> >> Signed-off-by: Matthias Brugger>> --- >> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 +--- >> 1 file changed, 25 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c >> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c >> index dd249cf5121e..5a263aa3ab6e 100644 >> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c >> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c >> @@ -21,6 +21,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -392,9 +393,10 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] >> = { >> >> static int mtk_drm_probe(struct platform_device *pdev) >> { >> +struct mmsys_dev *mmsys_private; >> struct device *dev = >dev; >> struct mtk_drm_private *private; >> -struct device_node *node; >> +struct device_node *node, *parent_node; >> struct component_match *match = NULL; >> int ret; >> int i; >> @@ -407,12 +409,23 @@ static int mtk_drm_probe(struct platform_device *pdev) >> INIT_WORK(>commit.work, mtk_atomic_work); >> private->data = of_device_get_match_data(dev); >> >> -private->config_regs = syscon_node_to_regmap(dev->of_node); >> -if (IS_ERR(private->config_regs)) >> -return PTR_ERR(private->config_regs); >> +/* Check if called from mfd */ >> +if (!dev->of_node) { >> +mmsys_private = dev_get_drvdata(pdev->dev.parent); > > Why do you directly access parent's driver data? You just need the > device node of mmsys, maybe you could refer to [1]. > > [1] > https://elixir.free-electrons.com/linux/latest/source/drivers/reset/reset-berlin.c#L78 > The difference is, that the driver you mentioned gets probed via device tree matching, while we get invoked here through the id_table. So there is no device node (the if actually checkes for pdev->dev.of_node to identify exactly this case). Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
The Emerging Display Technology ETM0700G0BDH6 is exactly the same display as the ETM0700G0DH6, exept the pixelclock polarity. Therefore re-use the ETM0700G0DH6 modes. It is used by default on emtrion Avari based development kits. Signed-off-by: Jan Tuerk--- .../bindings/display/panel/edt,etm0700g0bdh6.txt | 9 + drivers/gpu/drm/panel/panel-simple.c | 15 +++ 2 files changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt diff --git a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt new file mode 100644 index ..099e30bfa17f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt @@ -0,0 +1,9 @@ +Emerging Display Technology Corp. ETM0700G0BDH6 7.0" WVGA TFT LCD panel + +Required properties: + compatible: "edt,etm0700g0bdh6" + +This panel is exactly the same as ETM0700G0DH6 except the pixelclock polarity. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index b7c4709f7b34..42442034b53e 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -886,6 +886,18 @@ static const struct panel_desc edt_etm0700g0dh6 = { .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE, }; +static const struct panel_desc edt_etm0700g0bdh6 = { + .modes = _etm0700g0dh6_mode, + .num_modes = 1, + .bpc = 6, + .size = { + .width = 152, + .height = 91, + }, + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE, +}; + static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = { .clock = 32260, .hdisplay = 800, @@ -2029,6 +2041,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "edt,etm0700g0dh6", .data = _etm0700g0dh6, }, { + .compatible = "edt,etm0700g0bdh6", + .data = _etm0700g0bdh6, + }, { .compatible = "foxlink,fl500wvr00-a0t", .data = _fl500wvr00_a0t, }, { -- 2.11.0 emtrion GmbH Kreativpark - Alter Schlachthof 45 76131 Karlsruhe GERMANY http://www.emtrion.de ___ Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH
emtrion is a system integrator and manufacturer of embedded systems. Website: https://www.emtrion.de Signed-off-by: Jan Tuerk--- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 0994bdd82cd3..5215c5767260 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -102,6 +102,7 @@ eetieGalax_eMPIA Technology Inc elan Elan Microelectronic Corp. embest Shenzhen Embest Technology Co., Ltd. emmicroEM Microelectronic +emtrionemtrion GmbH energymicroSilicon Laboratories (formerly Energy Micro AS) engicamEngicam S.r.l. epcos EPCOS AG -- 2.11.0 emtrion GmbH Kreativpark - Alter Schlachthof 45 76131 Karlsruhe GERMANY http://www.emtrion.de ___ Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers
Hi Daniel, [somehow my email address seems to have gotten lost, so only saw this by chance on the list itself now. I've also re-added Sandy to the recipients] Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter: > On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote: > > For personal reasons, Mark Yao will leave rockchip, > > can not continue maintain drm/rockchip, Sandy Huang > > will take over the drm/rockchip. > > > > Cc: Sandy Huang> > Cc: Heiko Stuebner > > > > Signed-off-by: Mark Yao > > Since rockchip is in drm-misc that means we need a new maintainer who also > has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be > the new maintainer we need to fix that. > > Also, Heiko, are you interested in becoming co-maintainer? With commit > rights and all. I always feel somewhat inadequate judging the fast-paced drm stuff, as in the past once I got my head wrapped around something, drm always somehow moved another mile already ;-) . But somewhere I read that drm-pace for big changes is supposed to slow a bit now that atomic modesetting is done in a lot of places, so we could give co-maintainership for the Rockchip-drm a try - with Sandy wearing the actual hat for big changes though ;-) . Heiko > -Daniel > > > --- > > MAINTAINERS | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 0d77f22..31bf080 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4627,7 +4627,7 @@ F: > > Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > > F: Documentation/devicetree/bindings/display/renesas,du.txt > > > > DRM DRIVERS FOR ROCKCHIP > > -M: Mark Yao > > +M: Sandy Huang > > L: dri-devel@lists.freedesktop.org > > S: Maintained > > F: drivers/gpu/drm/rockchip/ > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 4.9.62: intermittent flicker after upgrade from 4.9.61
Greg KH wrote: > On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote: >> Rainer Fiebig wrote: >>> Maarten Lankhorst wrote: Op 20-11-17 om 09:51 schreef Rainer Fiebig: > Jani Nikula wrote: >> On Sun, 19 Nov 2017, Greg KHwrote: >>> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: Greg KH wrote: > On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote: >> Greg KH wrote: >>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote: Greg KH wrote: > On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote: >> Hi! >> >> Hopefully the right addressee. >> >> Encountered two bad backports which cause screen-flicker. >> dmesg shows: >> >> ... >> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO >> underrun >> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO >> underrun >> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO >> underrun >> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO >> underrun >> ... >> >> CPU: Intel Core i3 (Clarkdale/Ironlake) >> >> The backports are: >> >> - diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 49de476..277a802 100644 >> - diff --git a/drivers/gpu/drm/i915/intel_drv.h >> b/drivers/gpu/drm/i915/intel_drv.h >> index a19ec06..3ce9ba3 100644 >> >> After reversing them the flicker is gone, no more messages in >> dmesg. All >> else OK so far. > So which commit was the one that caused the problem? I will be > glad to > revert it. > > thanks, > > greg k-h > > I started by reverting the more complex one first ("index 49de476..277a802100644"). But the kernel wouldn't compile then. >>> What git commit id is that? I don't see those ids in the 4.9-stable >>> tree. >>> So I also reverted "index a19ec06..3ce9ba3 100644". After that the kernel compiled just fine and the problems were gone (still are). >>> Same here, what git commit id was this? >>> >>> thanks, >>> >>> greg k-h >>> >> OK, no mistake. IIRC, I took the patches (and the IDs) from the >> changelog for patch-4.9.62. I've attached both, so you can check >> yourself. >> >> I've also applied a freshly downloaded patch-4.9.62 to a freshly >> expanded 4.9 and re-compiled. The flicker is there. I haven't yet >> reverted the two patches but I'm confident that after having done so >> the >> flicker will be gone. If not I'll let you know. >> >> As a good news: 4.14 is *not* affected. So to me it seems those two >> patches are part of sort of a package and can not be backported >> alone. >> >> So long! >> Rainer Fiebig >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 49de476..277a802 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -27,6 +27,7 @@ >> >> #include >> #include >> +#include >> #include "i915_drv.h" >> #include "intel_drv.h" >> #include "../../../platform/x86/intel_ips.h" >> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct >> drm_i915_private *dev_priv, >> const struct intel_crtc *intel_crtc, >> int level, >> struct intel_crtc_state *cstate, >> - struct intel_plane_state *pristate, >> - struct intel_plane_state *sprstate, >> - struct intel_plane_state *curstate, >> + const struct intel_plane_state >> *pristate, >> + const struct intel_plane_state >> *sprstate, >> + const struct intel_plane_state >> *curstate, >> struct intel_wm_level *result) >> { >> uint16_t pri_latency = dev_priv->wm.pri_latency[level]; >> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct >> intel_crtc_state
[PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
Adding the label cpu0 allows the adjustment of cpu-parameters by reference in overlaying dtsi files in the same way as it is possible for imx6q devices. Signed-off-by: Jan Tuerk--- arch/arm/boot/dts/imx6dl.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi index 4d693a75ce98..623c12519b81 100644 --- a/arch/arm/boot/dts/imx6dl.dtsi +++ b/arch/arm/boot/dts/imx6dl.dtsi @@ -21,7 +21,7 @@ #address-cells = <1>; #size-cells = <0>; - cpu@0 { + cpu0: cpu@0 { compatible = "arm,cortex-a9"; device_type = "cpu"; reg = <0>; -- 2.11.0 emtrion GmbH Kreativpark - Alter Schlachthof 45 76131 Karlsruhe GERMANY http://www.emtrion.de ___ Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] ARM: dts: Add support for emtrion emCON-MX6 series
This patch adds support for the emtrion GmbH emCON-MX6 modules. They are available with imx.6 Solo, Dual-Lite, Dual and Quad equipped with Memory from 512MB to 2GB (configured by U-Boot). Our default developer-Kit ships with the Avari baseboard and the EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari). The devicetree is split into the common part providing all module components and the basic support for all SoC versions (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant. Finally the support for the avari baseboard in the developer-kit configuration is provided by the emcon-avari dts files. Signed-off-by: Jan Tuerk--- Documentation/devicetree/bindings/arm/emtrion.txt | 13 + arch/arm/boot/dts/Makefile| 2 + arch/arm/boot/dts/imx6dl-emcon-avari.dts | 233 ++ arch/arm/boot/dts/imx6dl-emcon.dtsi | 37 + arch/arm/boot/dts/imx6q-emcon-avari.dts | 233 ++ arch/arm/boot/dts/imx6q-emcon.dtsi| 37 + arch/arm/boot/dts/imx6qdl-emcon.dtsi | 849 ++ 7 files changed, 1404 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi diff --git a/Documentation/devicetree/bindings/arm/emtrion.txt b/Documentation/devicetree/bindings/arm/emtrion.txt new file mode 100644 index ..3ff6c6c2034d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/emtrion.txt @@ -0,0 +1,13 @@ +Emtrion Devicetree Bindings +=== + +emCON Series: +- + +Required root node properties + - compatible: + - "emtrion,emcon-mx6", "fsl,imx6q", "fsl,imx6dl"; : emCON-MX6 Generic SoM + - "emtrion,emcon-mx6", "fsl,imx6q"; : emCON-MX6D or emCON-MX6Q SoM + - "emtrion,emcon-mx6-avari", "fsl,imx6q"; : emCON-MX6D or emCON-MX6Q SoM on Avari Base + - "emtrion,emcon-mx6", "fsl,imx6dl";: emCON-MX6S or emCON-MX6DL SoM + - "emtrion,emcon-mx6-avari", "fsl,imx6dl"; : emCON-MX6S or emCON-MX6DL SoM on Avari Base diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index d0381e9caf21..5ce643ece228 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -373,6 +373,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \ imx6dl-colibri-eval-v3.dtb \ imx6dl-cubox-i.dtb \ imx6dl-dfi-fs700-m60.dtb \ + imx6dl-emcon-avari.dtb \ imx6dl-gw51xx.dtb \ imx6dl-gw52xx.dtb \ imx6dl-gw53xx.dtb \ @@ -424,6 +425,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \ imx6q-dfi-fs700-m60.dtb \ imx6q-display5-tianma-tm070-1280x768.dtb \ imx6q-dmo-edmqmx6.dtb \ + imx6q-emcon-avari.dtb \ imx6q-evi.dtb \ imx6q-gk802.dtb \ imx6q-gw51xx.dtb \ diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts b/arch/arm/boot/dts/imx6dl-emcon-avari.dts new file mode 100644 index ..f8ca63258eda --- /dev/null +++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts @@ -0,0 +1,233 @@ +/* + * Copyright (C) 2017 emtrion GmbH + * Author: Jan Tuerk + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + * + * SPDX-License-Identifier: GPL-2.0 + * + */ + +/dts-v1/; +#include "imx6dl.dtsi" +#include "imx6qdl-emcon.dtsi" +#include "imx6dl-emcon.dtsi" /*Include camera2 pinmux*/ + +/ { + model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari"; + compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl"; + + aliases { + mmc0 = + mmc2 = + mmc1 = + mmc3 = + }; + + chosen { + stdout-path = <>; + }; + + memory { + reg = <0x1000 0x4000>; + }; + + supplies { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + wallplug5p0: supply@0 { + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "WALL-PLUG"; + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + regulator-always-on; + regulator-boot-on; + }; + + base3p3: supply@1 { + compatible = "regulator-fixed"; + reg = <1>; +
Re: 4.9.62: intermittent flicker after upgrade from 4.9.61
Greg KH wrote: > On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote: >> Rainer Fiebig wrote: >>> Maarten Lankhorst wrote: Op 20-11-17 om 09:51 schreef Rainer Fiebig: > Jani Nikula wrote: >> On Sun, 19 Nov 2017, Greg KHwrote: >>> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: Greg KH wrote: > On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote: >> Greg KH wrote: >>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote: Greg KH wrote: > On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote: >> Hi! >> >> Hopefully the right addressee. >> >> Encountered two bad backports which cause screen-flicker. >> dmesg shows: >> >> ... >> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO >> underrun >> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO >> underrun >> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO >> underrun >> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO >> underrun >> ... >> >> CPU: Intel Core i3 (Clarkdale/Ironlake) >> >> The backports are: >> >> - diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 49de476..277a802 100644 >> - diff --git a/drivers/gpu/drm/i915/intel_drv.h >> b/drivers/gpu/drm/i915/intel_drv.h >> index a19ec06..3ce9ba3 100644 >> >> After reversing them the flicker is gone, no more messages in >> dmesg. All >> else OK so far. > So which commit was the one that caused the problem? I will be > glad to > revert it. > > thanks, > > greg k-h > > I started by reverting the more complex one first ("index 49de476..277a802100644"). But the kernel wouldn't compile then. >>> What git commit id is that? I don't see those ids in the 4.9-stable >>> tree. >>> So I also reverted "index a19ec06..3ce9ba3 100644". After that the kernel compiled just fine and the problems were gone (still are). >>> Same here, what git commit id was this? >>> >>> thanks, >>> >>> greg k-h >>> >> OK, no mistake. IIRC, I took the patches (and the IDs) from the >> changelog for patch-4.9.62. I've attached both, so you can check >> yourself. >> >> I've also applied a freshly downloaded patch-4.9.62 to a freshly >> expanded 4.9 and re-compiled. The flicker is there. I haven't yet >> reverted the two patches but I'm confident that after having done so >> the >> flicker will be gone. If not I'll let you know. >> >> As a good news: 4.14 is *not* affected. So to me it seems those two >> patches are part of sort of a package and can not be backported >> alone. >> >> So long! >> Rainer Fiebig >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 49de476..277a802 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -27,6 +27,7 @@ >> >> #include >> #include >> +#include >> #include "i915_drv.h" >> #include "intel_drv.h" >> #include "../../../platform/x86/intel_ips.h" >> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct >> drm_i915_private *dev_priv, >> const struct intel_crtc *intel_crtc, >> int level, >> struct intel_crtc_state *cstate, >> - struct intel_plane_state *pristate, >> - struct intel_plane_state *sprstate, >> - struct intel_plane_state *curstate, >> + const struct intel_plane_state >> *pristate, >> + const struct intel_plane_state >> *sprstate, >> + const struct intel_plane_state >> *curstate, >> struct intel_wm_level *result) >> { >> uint16_t pri_latency = dev_priv->wm.pri_latency[level]; >> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct >> intel_crtc_state
AW: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
Hi Fabio, I've used git send-email and tested the patches by checkpatch.pl before without any problems. So it might have been touched by the mail server, so can you send me your checkpatch.pl log (directly)? Regards, Jan Tuerk emtrion GmbH Kreativpark - Alter Schlachthof 45 76131 Karlsruhe GERMANY http://www.emtrion.de ___ Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
Am 23.11.2017 um 13:55 schrieb Jan Tuerk: > Adding the label cpu0 allows the adjustment of cpu-parameters > by reference in overlaying dtsi files in the same way as it > is possible for imx6q devices. > > Signed-off-by: Jan Tuerk> --- > arch/arm/boot/dts/imx6dl.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Andreas Färber Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 4.9.62: intermittent flicker after upgrade from 4.9.61
Rainer Fiebig wrote: > Maarten Lankhorst wrote: >> Op 20-11-17 om 09:51 schreef Rainer Fiebig: >>> Jani Nikula wrote: On Sun, 19 Nov 2017, Greg KHwrote: > On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: >> Greg KH wrote: >>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote: Greg KH wrote: > On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote: >> Greg KH wrote: >>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote: Hi! Hopefully the right addressee. Encountered two bad backports which cause screen-flicker. dmesg shows: ... [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun ... CPU: Intel Core i3 (Clarkdale/Ironlake) The backports are: - diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de476..277a802 100644 - diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a19ec06..3ce9ba3 100644 After reversing them the flicker is gone, no more messages in dmesg. All else OK so far. >>> So which commit was the one that caused the problem? I will be >>> glad to >>> revert it. >>> >>> thanks, >>> >>> greg k-h >>> >>> >> I started by reverting the more complex one first ("index >> 49de476..277a802100644"). But the kernel wouldn't compile then. > What git commit id is that? I don't see those ids in the 4.9-stable > tree. > >> So I also reverted "index a19ec06..3ce9ba3 100644". After that the >> kernel compiled just fine and the problems were gone (still are). > Same here, what git commit id was this? > > thanks, > > greg k-h > OK, no mistake. IIRC, I took the patches (and the IDs) from the changelog for patch-4.9.62. I've attached both, so you can check yourself. I've also applied a freshly downloaded patch-4.9.62 to a freshly expanded 4.9 and re-compiled. The flicker is there. I haven't yet reverted the two patches but I'm confident that after having done so the flicker will be gone. If not I'll let you know. As a good news: 4.14 is *not* affected. So to me it seems those two patches are part of sort of a package and can not be backported alone. So long! Rainer Fiebig diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de476..277a802 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -27,6 +27,7 @@ #include #include +#include #include "i915_drv.h" #include "intel_drv.h" #include "../../../platform/x86/intel_ips.h" @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv, const struct intel_crtc *intel_crtc, int level, struct intel_crtc_state *cstate, - struct intel_plane_state *pristate, - struct intel_plane_state *sprstate, - struct intel_plane_state *curstate, + const struct intel_plane_state *pristate, + const struct intel_plane_state *sprstate, + const struct intel_plane_state *curstate, struct intel_wm_level *result) { uint16_t pri_latency = dev_priv->wm.pri_latency[level]; @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate) struct intel_pipe_wm *pipe_wm; struct drm_device *dev = state->dev; const struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_plane *intel_plane; - struct intel_plane_state *pristate = NULL; - struct intel_plane_state
Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling
Regards Shashank On 11/17/2017 6:19 PM, Ville Syrjälä wrote: On Fri, Nov 17, 2017 at 05:50:11PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/17/2017 5:05 PM, Ville Syrjälä wrote: On Fri, Nov 17, 2017 at 08:49:49AM +0530, Sharma, Shashank wrote: Regards Shashank On 11/16/2017 9:53 PM, Ville Syrjälä wrote: On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjäläcommit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's handle this by considering the aspect ratio as a requirement for cea mode matching only if the passed in mode actually has a non-zero aspect ratio field. This will keep userspace that doesn't provide an aspect ratio working as before by matching it to the first otherwise equal cea mode. And once userspace starts to provide the aspect ratio it will be considerd a hard requirement for the match. Also change the hdmi mode matching to use drm_mode_match() for consistency, but we don't match on aspect ratio there since the spec doesn't list a specific aspect ratio for those modes. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma Cc: Jim Bride Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7220b8f9a7e8..00aa98f3e55d 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct drm_display_mode *mode) static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode *to_match, unsigned int clock_tolerance) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) return 0; + if (to_match->picture_aspect_ratio) + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; This doesn't look right. This means we are expecting a CEA mode without a pic aspect ratio field, which is invalid. No, it's perfectly valid. It's what we currently get from userspace. Yep, but that's due to missing Aspect ratio handling in the DRM layer. If that's fixed, as per the list of CEA modes, each CEA VIC contains an aspect ratio, which is a part of its unique identity. I guess once we have the aspect ratio handling in DRM layer, it would/should look like this: - EDID gives you all supported modes, including CEA modes with Aspect ratio - Userspcae gets the mode information, with aspect ratio (for CEA modes) If ( Userspace picks one of the CEA modes) - sends a modeset - we find a matching CEA VIC, found one from modedb - we load this VIC = nonzero information in AVI IF VIC field, else - sends a modeset - we could not find a matching CEA VIC, as aspect ratio is 0 - we make VIC field in AVI IF as 0a No. That would break current userspace. I guess I forgot to make it clear, that userspace will set the cap, only then we will provide aspect ratio information. So this should not break userspace, isn't it ? This is important, as HDMI compliance test 7-27 inspects if the VIC field in the AVI IF is accurate. Complicance is secondary to not breaking things that work. Also I find it hard to see what purpose there is in having a complicance test that sets a CEA modes w/o aspect ratio and then expects the infoframe to have VIC 0. Again, typically this is how these analyzers force modeset: - They send EDID with only one mode, which is the test mode, with aspect ratio. - They expect that VIC to be present in AVI IF - Shashank Ankit is going to publish the aspect ratio patch series again, with proper DRM cap and flags check. Would it be ok if we have a look that handling first ? This patch will be needed by that work. Otherwise we're going to stop sending a VIC for CEA modes with current userspace. I guess we should force userspaces to start bothering about aspect ratio field, right now we are doing this for Wayland based compositors, may be we should extend it to X based too. Yes, I've been saying that someone should look into extending the randr protocol with the necessary bits. But that still doesn't allow us to change the current behaviour as old userspace would anyway linger around for a long time. I think cap will cove this part The cap is irrelevant to this discussion. It
[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)
https://bugs.freedesktop.org/show_bug.cgi?id=103370 --- Comment #42 from Michel Dänzer--- (In reply to Robert Liu from comment #41) > Another issue found is when removing the adapter, the system goes to > suspend. That's not directly related to graphics drivers. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes
Regards Shashank On 11/17/2017 5:08 PM, Ville Syrjälä wrote: On Fri, Nov 17, 2017 at 08:53:54AM +0530, Sharma, Shashank wrote: Regards Shashank On 11/16/2017 9:56 PM, Ville Syrjälä wrote: On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville SyrjäläIf the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the infoframe as it's only capable of signalling none, 4:3, and 16:9. Currently we're sending these bogus infoframes whenever the cea mode specifies some other aspect ratio. Cc: Shashank Sharma Cc: Sean Paul Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 00aa98f3e55d..bafb3ee4ea97 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, const struct drm_display_mode *mode, bool is_hdmi2_sink) { + enum hdmi_picture_aspect picture_aspect; int err; if (!frame || !mode) @@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, * Populate picture aspect ratio from either * user input (if specified) or from the CEA mode list. */ - if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 || - mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) - frame->picture_aspect = mode->picture_aspect_ratio; - else if (frame->video_code > 0) - frame->picture_aspect = drm_get_cea_aspect_ratio( - frame->video_code); + picture_aspect = mode->picture_aspect_ratio; + if (picture_aspect == HDMI_PICTURE_ASPECT_NONE) + picture_aspect = drm_get_cea_aspect_ratio(frame->video_code); This is slightly going in the loop. - During the modeset the driver cant specify the aspect ratio information, as DRM layer lacks this support. - So we fill the VIC field, by comparing the mode with the DRM_CEA_MODES[] list. This will pick the first mode available in the list (regardless of its aspect ratio), and fill the VIC, as we don't consider aspect ratio while comparing timings. - Again, now while sending the aspect ratio, we are picking up the VIC, which may not be correct. So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is first in list, we will always pick 4:3 aspect ratio. Yes. The user didn't care about the aspect ratio (or rather couldn't specify one) so we just pick one. Which is exactly what we've been doing ever since we started sending the VIC in the infoframe. Correct, and we are hoping that this should be better (if not fixed) with the aspect ratio support patches + DRM cap. If the userspace doesn't set the cap, then anyways there is no aspect ratio field available, and VIC would be always 0, as this becomes a Non CEA mode. Or do you think it would be a better idea to send some VIC instead of No VIC, when userspace doesn't set the DRM cap for aspect ratio ? Yes. That's the current behaviour. IIRC some crappy amplifiers etc. with HDMI passthrough don't even work correctly unless VIC is specified. Hence we do want to send it whenever possible. Ok, in this case this make sense, and then I kindof agree with what this patch is trying to do. Reviewed-by: Shashank Sharma - Shashank - Shashank + /* +* The infoframe can't convey anything but none, 4:3 +* and 16:9, so if the user has asked for anything else +* we can only satisfy it by specifying the right VIC. +*/ + if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) { + if (picture_aspect != + drm_get_cea_aspect_ratio(frame->video_code)) + return -EINVAL; + picture_aspect = HDMI_PICTURE_ASPECT_NONE; + } + + frame->picture_aspect = picture_aspect; frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE; frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > Move the plane clip rectangle handling into > drm_atomic_helper_check_plane_state(). Drivers no longer > have to worry about such mundane details. > > Cc: Laurent Pinchart > Cc: Daniel Vetter > Suggested-by: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +-- > drivers/gpu/drm/arm/malidp_planes.c | 7 +-- > drivers/gpu/drm/armada/armada_overlay.c | 6 +- > drivers/gpu/drm/drm_atomic_helper.c | 12 +++- > drivers/gpu/drm/drm_plane_helper.c | 11 +++ > drivers/gpu/drm/drm_simple_kms_helper.c | 6 -- > drivers/gpu/drm/i915/intel_display.c| 12 > drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +-- > drivers/gpu/drm/meson/meson_plane.c | 7 +-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ > drivers/gpu/drm/nouveau/nv50_display.c | 12 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-- > drivers/gpu/drm/tegra/dc.c | 7 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +-- > drivers/gpu/drm/zte/zx_plane.c | 13 + > include/drm/drm_atomic_helper.h | 1 - > include/drm/drm_plane_helper.h | 1 - > 18 files changed, 22 insertions(+), 122 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c > index fa852fc1c9e6..93c503b754ba 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs > hdlcd_crtc_helper_funcs = { > static int hdlcd_plane_atomic_check(struct drm_plane *plane, > struct drm_plane_state *state) > { > - struct drm_rect clip = { 0 }; > struct drm_crtc_state *crtc_state; > u32 src_h = state->src_h >> 16; > > @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane > *plane, > return -EINVAL; > } > > - if (crtc_state->enable) > - drm_mode_get_hv_timing(_state->mode, > -, ); > - > - return drm_atomic_helper_check_plane_state(state, crtc_state, , > + return drm_atomic_helper_check_plane_state(state, crtc_state, > DRM_PLANE_HELPER_NO_SCALING, > DRM_PLANE_HELPER_NO_SCALING, > false, true); > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > b/drivers/gpu/drm/arm/malidp_planes.c > index 2f6d608d6eaf..e630c0218aaf 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane > *mp, > struct drm_crtc_state *crtc_state = > drm_atomic_get_existing_crtc_state(state->state, state->crtc); > struct malidp_crtc_state *mc; > - struct drm_rect clip = { 0 }; > u32 src_w, src_h; > int ret; > > if (!crtc_state) > return -EINVAL; > > - if (crtc_state->enable) > - drm_mode_get_hv_timing(_state->mode, > -, ); > - > - ret = drm_atomic_helper_check_plane_state(state, crtc_state, , > + ret = drm_atomic_helper_check_plane_state(state, crtc_state, > 0, INT_MAX, true, true); > if (ret) > return ret; For the hdlcd and malidp changes above: Acked-by: Liviu Dudau Best regards, Liviu > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index b411b608821a..564bd63a5f6a 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++ b/drivers/gpu/drm/armada/armada_overlay.c > @@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct > drm_crtc *crtc, > .x2 = crtc_x + crtc_w, > .y2 = crtc_y + crtc_h, > }; > - const struct drm_rect clip = { > - .x2 = crtc->mode.hdisplay, > - .y2 = crtc->mode.vdisplay, > - }; > uint32_t val, ctrl0; > unsigned idx = 0; > bool visible; > @@ -124,7 +120,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct > drm_crtc *crtc, >crtc_x, crtc_y, crtc_w, crtc_h, >src_x, src_y, src_w, src_h); > > - ret = drm_plane_helper_check_update(plane, crtc, fb, , , , > + ret = drm_plane_helper_check_update(plane, crtc, fb, , , >
Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage
On Thu, Nov 23, 2017 at 09:24:11AM +0100, Boris Brezillon wrote: > On Wed, 22 Nov 2017 16:13:31 -0800 > Eric Anholtwrote: > > > Boris Brezillon writes: > > > > > On Wed, 22 Nov 2017 13:16:08 -0800 > > > Eric Anholt wrote: > > > > > >> Boris Brezillon writes: > > >> > > >> > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's > > >> > passed a refcount object that has its counter set to 0. In this driver, > > >> > this is a valid use case since we want to increment ->usecnt only when > > >> > the BO object starts to be used by real HW components and this is > > >> > definitely not the case when the BO is created. > > >> > > > >> > Fix the problem by using refcount_inc_not_zero() instead of > > >> > refcount_inc() and fallback to refcount_set(1) when > > >> > refcount_inc_not_zero() returns false. Note that this 2-steps operation > > >> > is not racy here because the whole section is protected by a mutex > > >> > which guarantees that the counter does not change between the > > >> > refcount_inc_not_zero() and refcount_set() calls. > > >> > > >> If we're not following the model, and protecting the refcount by a > > >> mutex, shouldn't we just be using addition and subtraction instead of > > >> refcount's atomics? > > > > > > Actually, this mutex is protecting the bo->madv value which has to be > > > checked when the counter reaches 0 (when decrementing) or 1 (when > > > incrementing). We just benefit from this protection here, but ideally > > > it would be better to have an refcount_inc_allow_zero() as suggested by > > > Daniel. > > > > Let me restate this to see if it makes sense: The refcount is always >= > > 0, this is is the only path that increases the refcount from 0 to 1, and > > it's (incidentally) protected by a mutex, so there's no race between the > > attempted increase from nonzero and the set from nonzero to 1. > > Yep. > > > > > This seems fine to me as a bugfix. > > The discussion is going on in the other thread, let's wait a bit > before taking a decision. Let's not block the bugfix on reaching perfection imo. I'd merge this as the minimal fix, and then apply the pretty paint once we have a clear idea for that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver
https://bugs.freedesktop.org/show_bug.cgi?id=92827 --- Comment #6 from Maximilian Böhm--- No, it will be merged with Linux 4.15 but you will still need an kernel parameter: https://www.phoronix.com/scan.php?page=news_item=AMDGPU-DC-Accepted Until then, you have to compile yourself a patched kernel. For Arch-based distros you can use the AUR linux-amd-staging-drm-next-git. Phoronix provides pre-compiled packages for Ubuntu. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103791] Tearing after screen wakeup/on
https://bugs.freedesktop.org/show_bug.cgi?id=103791 --- Comment #6 from denisgolo...@yandex.ru --- Created attachment 135701 --> https://bugs.freedesktop.org/attachment.cgi?id=135701=edit dmesg + debug -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] video: udlfb: Delete an error message for a failed memory allocation in two functions
From: Markus ElfringDate: Fri, 24 Nov 2017 21:12:54 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/udlfb.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c index d44f14242016..77633c58bb9b 100644 --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -1175,10 +1175,8 @@ static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info *info) * Alloc system memory for virtual framebuffer */ new_fb = vmalloc(new_len); - if (!new_fb) { - pr_err("Virtual framebuffer alloc failed\n"); + if (!new_fb) goto error; - } if (info->screen_base) { memcpy(new_fb, old_fb, old_len); @@ -1599,10 +1597,8 @@ static int dlfb_usb_probe(struct usb_interface *interface, usbdev = interface_to_usbdev(interface); dev = kzalloc(sizeof(*dev), GFP_KERNEL); - if (dev == NULL) { - dev_err(>dev, "dlfb_usb_probe: failed alloc of dev struct\n"); + if (!dev) goto error; - } kref_init(>kref); /* matching kref_put in usb .disconnect fn */ -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/13] drm/tegra: kick out simplefb
On Fri, Nov 24, 2017 at 06:53:34PM +0100, Michał Mirosław wrote: > Kick out firmware fb when loading tegra driver. > > Signed-off-by: Michał Mirosław> --- > drivers/gpu/drm/tegra/drm.c | 4 > 1 file changed, 4 insertions(+) Cool. Can you provide some background on how you tested this? What is your firmware FB? That'd be useful information to put in the commit message. Also, nit: "tegra driver" -> "Tegra driver". Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] video-UDLFB: Adjustments for five function implementations
From: Markus ElfringDate: Fri, 24 Nov 2017 21:45:54 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete an error message for a failed memory allocation in two functions Return an error code only as a constant in dlfb_realloc_framebuffer() Improve a size determination in dlfb_alloc_urb_list() Delete an unnecessary return statement in two functions drivers/video/fbdev/udlfb.c | 23 +-- 1 file changed, 5 insertions(+), 18 deletions(-) -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()
From: Markus ElfringDate: Fri, 24 Nov 2017 22:22:06 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/stifb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c index 6ded5c198998..fe217a2f7d21 100644 --- a/drivers/video/fbdev/stifb.c +++ b/drivers/video/fbdev/stifb.c @@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct *sti, int bpp_pref) int bpp, xres, yres; fb = kzalloc(sizeof(*fb), GFP_ATOMIC); - if (!fb) { - printk(KERN_ERR "stifb: Could not allocate stifb structure\n"); + if (!fb) return -ENODEV; - } info = >info; -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual
Am Freitag, den 24.11.2017, 16:25 + schrieb Alexey Brodkin: > Hi Lucas, > > On Fri, 2017-11-24 at 17:11 +0100, Lucas Stach wrote: > > Hi Alexey, > > > > Am Freitag, den 24.11.2017, 16:02 + schrieb Alexey Brodkin: > > > > > > Hello, > > > > > > Being in the middle of bring-up of the new board with Vivante GPU (HSDK > > > namely, > > > see > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_arch_arc_plat-2Dhsdk=Dw > > > IDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL- > > > bLY=ZJSI1u6GgsRHNIcONVFfIKvn1AWaB38GmtCN1dGB3w0=) > > > I was looking at simple 3D test apps to see how Etnaviv works on the > > > hardware. > > > > > > So far I was able to get kmscube working perfectly fine and the next item > > > I took > > > was glxgears (for some reason I was under impression that's de facto > > > "Hello world" app > > > in the GPU world). But apparently even with Xserver up and running > > > glxgears doesn't work. > > > > > > Moreover I tried the same thing on Wandboard Quad but to no avail as well. > > > That's what I saw: > > > ->8- > > > # glxgears > > > Error: couldn't get an RGB, Double-buffered visual > > > > > > # glxinfo > > > name of display: :0 > > > Error: couldn't find RGB GLX visual or fbconfig > > > ->8- > > > > > > Googling didn't help here unfortunately so maybe some pointers could be > > > suggested here... like what do I do wrong and if glxgears is supposed to > > > work on top of DRM GPU at all? > > > > > > Thanks a lot in advance! > > > > For 3D acceleration to work under X you need the etnaviv specific DDX > > driver, which can be found here: > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunstable-2Ddevel=DwIDaQ=DPL6_ > > X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL- > > bLY=ZzK2fxA6_XlN6pGnf2Tpo6qKzzQh76ocWZ6IDR-WPtc= > > Thanks for the pointer, still a couple of questions below... > > > Don't let you get confused by the name, the armada driver implements > > support for both armada drm and imx-drm and the etnaviv DDX. This > > provides 2D acceleration on the Vivante 2D cores, as well a the DRI2/3 > > bit necessary to get a 3D context on X. > > From Wandboard's .dts I see that 2D core is a separate node with separate > set of registers mapped at a different location in memory, right? > > Do you know if that's possible if the same one memory-mapped register set > controls both 3D and 2D engine? Yes, a "core" in Vivante speak is a GPU with one DMA frontend. A single frontend can feed both 3D and 2D acceleration engines behind it. On i.MX6 the 2D and 3D engine are on separate cores, but Marvell Dove has a combined 2D/3D core. > If we happen to not have 2D core if that's a no go for us for anything? I don't know if the DDX works properly without 2D acceleration. Weston on the other hand only relies on the 3D accel core for doing compositing, so even if you don't have a 2D engine you will be able to launch a modern Linux graphics stack. The etnaviv DDX could also emulate 2D accel over the 3D core by using the X.Org glamor module, but no one has bothered to implement this yet. > > In the meantime I'll try to figure out if we have 2D core or not. You can find out what your GPU provides by looking at the feature bits. chipFeatures_PIPE_2D, chipFeatures_PIPE_3D and chipFeatures_PIPE_VG is what you are looking out for. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > Move the plane clip rectangle handling into > drm_atomic_helper_check_plane_state(). Drivers no longer > have to worry about such mundane details. > > Cc: Laurent Pinchart > Cc: Daniel Vetter > Suggested-by: Daniel Vetter > Signed-off-by: Ville Syrjälä I guess the longer-term next step would be that we expose can_scale and can_position (and maybe the scaling limits?) as read-only properties, as hints to the compositor. And then move all the calls into the overall helpers (i.e. drm_atomic_helper_check_planes). But this here is real sweet already I think. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +-- > drivers/gpu/drm/arm/malidp_planes.c | 7 +-- > drivers/gpu/drm/armada/armada_overlay.c | 6 +- > drivers/gpu/drm/drm_atomic_helper.c | 12 +++- > drivers/gpu/drm/drm_plane_helper.c | 11 +++ > drivers/gpu/drm/drm_simple_kms_helper.c | 6 -- > drivers/gpu/drm/i915/intel_display.c| 12 > drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +-- > drivers/gpu/drm/meson/meson_plane.c | 7 +-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ > drivers/gpu/drm/nouveau/nv50_display.c | 12 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-- > drivers/gpu/drm/tegra/dc.c | 7 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +-- > drivers/gpu/drm/zte/zx_plane.c | 13 + > include/drm/drm_atomic_helper.h | 1 - > include/drm/drm_plane_helper.h | 1 - > 18 files changed, 22 insertions(+), 122 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c > index fa852fc1c9e6..93c503b754ba 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs > hdlcd_crtc_helper_funcs = { > static int hdlcd_plane_atomic_check(struct drm_plane *plane, > struct drm_plane_state *state) > { > - struct drm_rect clip = { 0 }; > struct drm_crtc_state *crtc_state; > u32 src_h = state->src_h >> 16; > > @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane > *plane, > return -EINVAL; > } > > - if (crtc_state->enable) > - drm_mode_get_hv_timing(_state->mode, > -, ); > - > - return drm_atomic_helper_check_plane_state(state, crtc_state, , > + return drm_atomic_helper_check_plane_state(state, crtc_state, > DRM_PLANE_HELPER_NO_SCALING, > DRM_PLANE_HELPER_NO_SCALING, > false, true); > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > b/drivers/gpu/drm/arm/malidp_planes.c > index 2f6d608d6eaf..e630c0218aaf 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane > *mp, > struct drm_crtc_state *crtc_state = > drm_atomic_get_existing_crtc_state(state->state, state->crtc); > struct malidp_crtc_state *mc; > - struct drm_rect clip = { 0 }; > u32 src_w, src_h; > int ret; > > if (!crtc_state) > return -EINVAL; > > - if (crtc_state->enable) > - drm_mode_get_hv_timing(_state->mode, > -, ); > - > - ret = drm_atomic_helper_check_plane_state(state, crtc_state, , > + ret = drm_atomic_helper_check_plane_state(state, crtc_state, > 0, INT_MAX, true, true); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index b411b608821a..564bd63a5f6a 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++ b/drivers/gpu/drm/armada/armada_overlay.c > @@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct > drm_crtc *crtc, > .x2 = crtc_x + crtc_w, > .y2 = crtc_y + crtc_h, > }; > - const struct drm_rect clip = { > - .x2 = crtc->mode.hdisplay, > - .y2 = crtc->mode.vdisplay, > - }; > uint32_t val, ctrl0; > unsigned idx = 0; > bool visible; > @@ -124,7 +120,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct > drm_crtc *crtc, >crtc_x, crtc_y,
[PATCH] video/fbdev/wm8505fb: Delete an error message for a failed memory allocation in wm8505fb_probe()
From: Markus ElfringDate: Fri, 24 Nov 2017 20:22:10 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/wm8505fb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c index 253ffe9baab2..8f0d5379861d 100644 --- a/drivers/video/fbdev/wm8505fb.c +++ b/drivers/video/fbdev/wm8505fb.c @@ -276,10 +276,8 @@ static int wm8505fb_probe(struct platform_device *pdev) fbi = devm_kzalloc(>dev, sizeof(struct wm8505fb_info) + sizeof(u32) * 16, GFP_KERNEL); - if (!fbi) { - dev_err(>dev, "Failed to initialize framebuffer device\n"); + if (!fbi) return -ENOMEM; - } strcpy(fbi->fb.fix.id, DRIVER_NAME); -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video/fbdev/vt8500lcdfb: Delete an error message for a failed memory allocation in vt8500lcd_probe()
From: Markus ElfringDate: Fri, 24 Nov 2017 20:42:08 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/vt8500lcdfb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c index 1a1176bf0906..5c5cd2923041 100644 --- a/drivers/video/fbdev/vt8500lcdfb.c +++ b/drivers/video/fbdev/vt8500lcdfb.c @@ -289,10 +289,8 @@ static int vt8500lcd_probe(struct platform_device *pdev) fbi = devm_kzalloc(>dev, sizeof(struct vt8500lcd_info) + sizeof(u32) * 16, GFP_KERNEL); - if (!fbi) { - dev_err(>dev, "Failed to initialize framebuffer device\n"); + if (!fbi) return -ENOMEM; - } strcpy(fbi->fb.fix.id, "VT8500 LCD"); -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103791] Tearing after screen wakeup/on
https://bugs.freedesktop.org/show_bug.cgi?id=103791 --- Comment #7 from denisgolo...@yandex.ru --- See attached dmesg with debug. Tearing appeared after turning display on. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] video: udlfb: Return an error code only as a constant in dlfb_realloc_framebuffer()
From: Markus ElfringDate: Fri, 24 Nov 2017 21:22:25 +0100 * Return an error code without storing it in an intermediate variable. * Delete the label "error" and local variable "retval" which became unnecessary with this refactoring. Signed-off-by: Markus Elfring --- drivers/video/fbdev/udlfb.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c index 77633c58bb9b..cb2d59ca67a4 100644 --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -1159,7 +1159,6 @@ static struct fb_ops dlfb_ops = { */ static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info *info) { - int retval = -ENOMEM; int old_len = info->fix.smem_len; int new_len; unsigned char *old_fb = info->screen_base; @@ -1176,7 +1175,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info *info) */ new_fb = vmalloc(new_len); if (!new_fb) - goto error; + return -ENOMEM; if (info->screen_base) { memcpy(new_fb, old_fb, old_len); @@ -1203,11 +1202,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info *info) dev->backing_buffer = new_back; } } - - retval = 0; - -error: - return retval; + return 0; } /* -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] video: udlfb: Improve a size determination in dlfb_alloc_urb_list()
From: Markus ElfringDate: Fri, 24 Nov 2017 21:30:37 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/udlfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c index cb2d59ca67a4..059883962698 100644 --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -1867,7 +1867,7 @@ static int dlfb_alloc_urb_list(struct dlfb_data *dev, int count, size_t size) INIT_LIST_HEAD(>urbs.list); while (i < count) { - unode = kzalloc(sizeof(struct urb_node), GFP_KERNEL); + unode = kzalloc(sizeof(*unode), GFP_KERNEL); if (!unode) break; unode->dev = dev; -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] video: udlfb: Delete an unnecessary return statement in two functions
From: Markus ElfringDate: Fri, 24 Nov 2017 21:36:39 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions. Signed-off-by: Markus Elfring --- drivers/video/fbdev/udlfb.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c index 059883962698..c6bf7088f5f4 100644 --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -505,8 +505,6 @@ static void dlfb_compress_hline( *command_buffer_ptr = cmd; *pixel_start_ptr = pixel; *device_address_ptr = dev_addr; - - return; } /* @@ -1768,8 +1766,6 @@ static void dlfb_usb_disconnect(struct usb_interface *interface) kref_put(>kref, dlfb_free); /* consider dlfb_data freed */ - - return; } static struct usb_driver dlfb_driver = { -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hardware 3D acceleration doesn't work anymore with the latest git kernel
On 24.11.2017 20:14, Ilia Mirkin wrote: Do you have SWIOTLB disabled in your .config? Try enabling it to see if that's the issue. Looking at your bisect log, you might have incorrectly marked some revisions. E.g. you had a compile failure, which while isn't "good", it's also not "bad" -- good and bad are only in reference to the specific issue you're seeing. In such cases you can run "git bisect skip" which will mark the commit as "unknown" and pick a different one to try. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel Hi All, Success!! I enabled SWIOTLB and the hardware 3D acceleration works again! Fantastic. Thank you very much! And thank you for the hint with "git bisect skip". Cheers, Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=97909 Joonas Sarajärvichanged: What|Removed |Added CC||m...@iki.fi --- Comment #8 from Joonas Sarajärvi --- Just as an extra data point, this issue and the workaround from comment #5 seem to apply also to X-Plane 11. Tested with a Radeon RX 560 on Fedora 27 with the stock drivers. Currently this would be: kernel 4.13.12-300 mesa 17.2.4-2 With the MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory ./X-Plane-x86_64 workaround, the simulator works ok. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/15] drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangle
On Thu, Nov 23, 2017 at 09:04:59PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > No functional changes as the code already uses crtc_state->mode > to populate the clip, which is also what drm_mode_get_hv_timing() > uses. > > Once everyone agrees on this we can move the clip handling into > drm_atomic_helper_check_plane_state(). > > Cc: Laurent Pinchart > Cc: Thierry Reding > Cc: linux-te...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/tegra/dc.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) I assume you want to take this through drm-misc, so: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] drm: More plane clipping polish
On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > This series first unifies all users of drm_atomic_helper_check_plane_state() > to populate the clip rectangle with drm_mode_get_hv_timing(), and once > everything is unified the clip rectangle handling is sucked into > drm_atomic_helper_check_plane_state() away from driver code. > > Entire series available here: > git://github.com/vsyrjala/linux.git atomic_plane_helper_clip > > Cc: Archit Taneja > Cc: Ben Skeggs > Cc: Brian Starkey > Cc: CK Hu > Cc: Daniel Vetter > Cc: freedr...@lists.freedesktop.org > Cc: Laurent Pinchart > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-te...@vger.kernel.org > Cc: Liviu Dudau > Cc: Mali DP Maintainers > Cc: Mark Yao > Cc: Neil Armstrong > Cc: Noralf Trønnes > Cc: nouv...@lists.freedesktop.org > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Shawn Guo > Cc: Sinclair Yeh > Cc: Thierry Reding > Cc: Thomas Hellstrom > Cc: VMware Graphics > > Ville Syrjälä (15): > drm/i915: Reject odd pipe source width with double wide/dual link > drm/i915: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle > drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/meson: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle > drm: Don't pass clip to drm_atomic_helper_check_plane_state() > > drivers/gpu/drm/arm/hdlcd_crtc.c| 6 +- > drivers/gpu/drm/arm/malidp_planes.c | 5 + > drivers/gpu/drm/armada/armada_overlay.c | 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 12 +++- > drivers/gpu/drm/drm_plane_helper.c | 11 +++ > drivers/gpu/drm/drm_simple_kms_helper.c | 5 - > drivers/gpu/drm/i915/intel_atomic_plane.c | 8 > drivers/gpu/drm/i915/intel_display.c| 12 +++- > drivers/gpu/drm/i915/intel_drv.h| 1 - > drivers/gpu/drm/i915/intel_sprite.c | 8 ++-- > drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 6 +- > drivers/gpu/drm/meson/meson_plane.c | 6 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ > drivers/gpu/drm/nouveau/nv50_display.c | 8 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +--- > drivers/gpu/drm/tegra/dc.c | 8 +--- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +--- > drivers/gpu/drm/zte/zx_plane.c | 15 +-- > include/drm/drm_atomic_helper.h | 1 - > include/drm/drm_plane_helper.h | 1 - > 21 files changed, 35 insertions(+), 117 deletions(-) The series: Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
On Fri, Nov 24, 2017 at 11:59:45AM +, Liviu Dudau wrote: > On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä> > Hi Ville, > > > > > Move the plane clip rectangle handling into > > drm_atomic_helper_check_plane_state(). Drivers no longer > > have to worry about such mundane details. > > This is quite an important patch and I dare say the essence of your > series, right? Yet very few people got Cc-ed on it (1 AFAICT) and it > touches quite a few drivers. It has no functional changes, so forgetting to plaster it with Ccs doesn't seem all that dangerous. All the (potentially) functional changes were in the prep patches which had Ccs, as did the cover letter. And maintainers should read the ml anyway ;) -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers
On Fri, Nov 24, 2017 at 09:28:59AM +0100, Heiko Stuebner wrote: > Hi Daniel, > > [somehow my email address seems to have gotten lost, so > only saw this by chance on the list itself now. > I've also re-added Sandy to the recipients] > > Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter: > > On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote: > > > For personal reasons, Mark Yao will leave rockchip, > > > can not continue maintain drm/rockchip, Sandy Huang > > > will take over the drm/rockchip. > > > > > > Cc: Sandy Huang> > > Cc: Heiko Stuebner > > > > > > Signed-off-by: Mark Yao > > > > Since rockchip is in drm-misc that means we need a new maintainer who also > > has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be > > the new maintainer we need to fix that. > > > > Also, Heiko, are you interested in becoming co-maintainer? With commit > > rights and all. > > I always feel somewhat inadequate judging the fast-paced drm stuff, as in > the past once I got my head wrapped around something, drm always > somehow moved another mile already ;-) . > > But somewhere I read that drm-pace for big changes is supposed to slow a > bit now that atomic modesetting is done in a lot of places, so we could give > co-maintainership for the Rockchip-drm a try - with Sandy wearing the > actual hat for big changes though ;-) . Yeah I think on the modeset side it calmed down a lot. We're still fine-tuning the helper libraries as we're figuring out better ways to write drivers. But right now I think a lot of the action is all in details not relevant for many drivers. If Sandy's ok with that too pls request an fd.o account for drm-misc and set up the tooling per our quickstart guide: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html#quickstart Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer
On Thu, Nov 23, 2017 at 02:13:08PM +0200, Jani Nikula wrote: > I'm juggling too many things, and drm-misc maintenance is one that I > keep dropping on the floor. Admit reality and remove myself as > maintainer. This still leaves us with a nice team of three who are > actually doing the drm-misc work, while I focus on drm-intel. Thanks a lot for the work done! > Cc: Daniel Vetter> Cc: Gustavo Padovan > Cc: Sean Paul > Cc: Dave Airlie > Signed-off-by: Jani Nikula Acked-by: Daniel Vetter Sean is getting stuffed with turkey and Gustova is on vacation, so will probably take until next week for those acks to roll in. Thanks, Daniel > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9a9d3fdc55ef..fb8820458a7f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4490,7 +4490,6 @@ F: include/linux/vga* > > DRM DRIVERS AND MISC GPU PATCHES > M: Daniel Vetter > -M: Jani Nikula > M: Gustavo Padovan > M: Sean Paul > W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html > -- > 2.11.0 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hardware 3D acceleration doesn't work anymore with the latest git kernel
Hi All, I bisected today and the first bad commit is: a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions to populate/map in one call (v2)) [1] Please find attached the git bisect log. Thanks, Christian [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4dec819c8bba6365eb893a4ca88db4dd1210110 On 22.11.2017 14:45, Ilia Mirkin wrote: I thought I covered that... "I'd recommend doing a proper bisect (search for "git bisect", there are tons of guides). That will identify the commit that's actually responsible." -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel git bisect start git bisect good 894025f24bd028942da3e602b87d9f7223109b14 (Linux 4.15 alpha1 Mon Nov 13 21:14:07 2017 -0800) git bisect bad e60e1ee60630cafef5e430c2ae364877e061d980 Output: Bisecting: 2555 revisions left to test after this (roughly 12 steps) [5bbcc0f595fadb4cac0eddc4401035ec0bd95b09] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good Output: Bisecting: 1277 revisions left to test after this (roughly 10 steps) [9a45ddaaa674aa103cd74a0df9a3f9c2c8fb3124] drm/nouveau/mmu: implement page table cache git bisect bad Output: Bisecting: 638 revisions left to test after this (roughly 9 steps) [d6c0511300dcff19969844495ba293c4efb50b42] drm/i915/execlists: Distinguish the incomplete context notifies git bisect bad Output: Bisecting: 373 revisions left to test after this (roughly 8 steps) [ae7617f0ef1820be033eef93859a6bb6174a843f] drm/i915: Allow optimized platform checks git bisect good Output: Bisecting: 186 revisions left to test after this (roughly 8 steps) [6e2e216fadd80b4280783bb78e543593ebf2cb69] drm/amdgpu:use formal register to trigger hdp invalidate git bisect bad Output: Bisecting: 93 revisions left to test after this (roughly 7 steps) [b72cf4fca2bb786e20864b5e8755105aa9626fb4] drm/amdgpu: move taking mmap_sem into get_user_pages v2 git bisect bad Output: Bisecting: 46 revisions left to test after this (roughly 6 steps) [c5927537dd5706b17affa8aeea28c7b19c8fbb42] drm/amd: Remove null check before kfree git bisect bad Output: Bisecting: 22 revisions left to test after this (roughly 5 steps) [e719d5169f75ead3c05329b4125afb67b4f33eba] drm/amd/include: Add hdmi_redriver_set to atomfirmware git bisect good Output: Bisecting: 11 revisions left to test after this (roughly 4 steps) [925d5d798f465671c6b8011e80c636da46ef1a16] drm/amdgpu/gfx8: apply dynamic cu mask to APUs as well git bisect bad Output: Bisecting: 5 revisions left to test after this (roughly 3 steps) [db95e2185523ee9d46a13ceee37bffe8442d2e1c] drm/amdgpu: Add debugfs file for VBIOS and version git bisect bad Output: Bisecting: 2 revisions left to test after this (roughly 1 step) [7405e0dad4c75b33976ddd997513635d7a0204b1] drm/amd/amdgpu: Use new TTM populate/map helper function CC drivers/gpu/drm/ttm/ttm_page_alloc.o drivers/gpu/drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of ‘ttm_populate_and_map_pages’ int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt) ^~ In file included from drivers/gpu/drm/ttm/ttm_page_alloc.c:49:0: ./include/drm/ttm/ttm_page_alloc.h:120:19: note: previous definition of ‘ttm_populate_and_map_pages’ was here static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt) ^~ drivers/gpu/drm/ttm/ttm_page_alloc.c:950:6: error: redefinition of ‘ttm_unmap_and_unpopulate_pages’ void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt) ^~ In file included from drivers/gpu/drm/ttm/ttm_page_alloc.c:49:0: ./include/drm/ttm/ttm_page_alloc.h:125:20: note: previous definition of ‘ttm_unmap_and_unpopulate_pages’ was here static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt) git bisect bad Output: Bisecting: 0 revisions left to test after this (roughly 0 steps) [a4dec819c8bba6365eb893a4ca88db4dd1210110] drm/ttm: Add helper functions to populate/map in one call (v2) git bisect bad Output: a4dec819c8bba6365eb893a4ca88db4dd1210110 is the first bad commit commit a4dec819c8bba6365eb893a4ca88db4dd1210110 Author: Tom St DenisDate: Fri Aug 18 10:04:57 2017 -0400 drm/ttm: Add helper functions to populate/map in one call (v2) These functions replace a section of common code found in radeon/amdgpu drivers (and possibly others) as part of the ttm_tt_*populate() callbacks. v2: squash in fix for sw iommu from Tom Signed-off-by: Tom St Denis Reviewed-by: Christian König Signed-off-by: Alex Deucher :04 04
[GIT PULL] hdlcd: fixes for drm-next
Hi Dave, Cleaning up the backlog of patches that I have in my tree, they have all been baking in linux-next for weeks. Minor fixes that could be sent as late -rc but I'm not in any rush, so queueing them for v4.16 is fine. Many thanks, Liviu The following changes since commit c209101fc1c91a318422733a3721ff6a9ff7899f: Merge tag 'drm-misc-fixes-2017-11-20' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-24 11:33:29 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/hdlcd for you to fetch changes up to 7e2410d3b50f749fb0fa3844ae71da52717c48ee: drm/arm: Replace instances of drm_dev_unref with drm_dev_put. (2017-11-24 14:15:29 +) Liviu Dudau (1): drm: hdlcd: Update PM code to save/restore console. Srishti Sharma (1): drm/arm: Replace instances of drm_dev_unref with drm_dev_put. Vitor Massaru Iha (1): drm: Fix checkpatch issue: "WARNING: braces {} are not necessary for single statement blocks." drivers/gpu/drm/arm/hdlcd_crtc.c | 3 +-- drivers/gpu/drm/arm/hdlcd_drv.c | 9 ++--- 2 files changed, 7 insertions(+), 5 deletions(-) -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer
On Thu, Nov 23, 2017, 7:12 AM Jani Nikulawrote: > I'm juggling too many things, and drm-misc maintenance is one that I > keep dropping on the floor. Admit reality and remove myself as > maintainer. This still leaves us with a nice team of three who are > actually doing the drm-misc work, while I focus on drm-intel. > > Cc: Daniel Vetter > Cc: Gustavo Padovan > Cc: Sean Paul > Cc: Dave Airlie > Signed-off-by: Jani Nikula > :( Relunctantly-Acked-By: Sean Paul --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9a9d3fdc55ef..fb8820458a7f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4490,7 +4490,6 @@ F:include/linux/vga* > > DRM DRIVERS AND MISC GPU PATCHES > M: Daniel Vetter > -M: Jani Nikula > M: Gustavo Padovan > M: Sean Paul > W: > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html > -- > 2.11.0 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
On 2017-11-24 03:29 PM, Christian Zigotzky wrote: > Hi All, > > I bisected today and the first bad commit is: > a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions > to populate/map in one call (v2)) [1] It can't really be that commit, since it just adds functions but doesn't hook them up anywhere. Presumably it's commit f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM populate/dma map helper functions") instead, which makes the radeon driver rely on ttm_populate_and_map_pages, which is just a stub returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled. I can see two possible solutions: 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without SWIOTLB / INTEL_IOMMU as well. 2. Make the drivers work without ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages again in that case. Solution 1 would be preferable. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes
On Thu, Nov 23, 2017 at 03:14:46PM -0500, Ilia Mirkin wrote: > On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä >wrote: > > On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote: > >> We need to shift the values up, otherwise we'd end up with a negative > >> shift. This works for up-to 16-bit components, which is fine for now. > > > > Shouldn't we actually replicate the high bits in the low bits? > > Not entirely sure what you're proposing... > > Ideally we wouldn't be lazy and pass e.g. 16-bit values to MAKE_RGBA > which would then shift down as necessary (and even there, you could > end up with off-by-1's maybe?). For e.g. 0xff, that should become > 0x3ff but with my code will become 0x3fc. Exactly the issue. > But for other values, it's > less clear what to do with the low bits. I figured it didn't really > matter. > > Do you have a concrete proposal? The usual thing would be just (value) * 0x3ff / 0xff or ((value) << 2) | ((value) >> 6) -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
Hi Jan, On Thu, Nov 23, 2017 at 1:18 PM, Türk, Janwrote: > Hi Fabio, > > I've used git send-email and tested the patches by checkpatch.pl before > without any problems. > So it might have been touched by the mail server, so can you send me your > checkpatch.pl log (directly)? Take a look at your patch here: https://patchwork.kernel.org/patch/10072765/ Click in the "patch" link and download it. You will notice that all tabs have been converted into spaces. checkpatch will warn about it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle
On Fri, Nov 24, 2017 at 03:32:22PM +0100, Philipp Zabel wrote: > On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote: > > From: Ville Syrjälä> > > > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > > > No functional changes as the code already uses crtc_state->mode > > to populate the clip, which is also what drm_mode_get_hv_timing() > > uses. > > I don't understand this explanation, drm_mode_get_hv_timing uses > whichever mode is passed to it? Hmm. I worded that badly it seems. The point is that we pass the user mode everywhere else where we want to know the dimensions of the crtc coordinate space. > > > Once everyone agrees on this we can move the clip handling into > > drm_atomic_helper_check_plane_state(). > > I can see that there are no functional changes though, > > Acked-by: Philipp Zabel > > regards > Philipp -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly
On Fri, Nov 24, 2017 at 04:35:10PM +0100, Maarten Lankhorst wrote: > Op 24-11-17 om 16:03 schreef Daniel Vetter: > > On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote: > >> This was implemented correctly only on the atomic ioctl before, but > >> it should really be working on all 3 ioctl's involved, so ensure we > >> always set crtc_id correctly with a testcase. > >> > >> Signed-off-by: Maarten Lankhorst> > We seemt to completely lack these checks for the vblank ioctl and the > > atomic ioctl too. Can you pls fill these gaps (probably best in kms_flip.c > > and kms_atomic.c), too? > Summary is a bit out of date, but I did add them in here. :) Oh was blind. > >> --- > >> tests/kms_vblank.c | 60 > >> ++ > >> 1 file changed, 56 insertions(+), 4 deletions(-) > >> > >> diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c > >> index 47fd10fb9078..004f0e6104ee 100644 > >> --- a/tests/kms_vblank.c > >> +++ b/tests/kms_vblank.c > >> @@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void > >> (*testfunc)(data_t *, int, int)) > >>igt_display_t *display = >display; > >>igt_output_t *output; > >>enum pipe p; > >> - unsigned int valid_tests = 0; > >> > >>for_each_pipe_with_valid_output(display, p, output) { > >>igt_hang_t hang; > >> @@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void > >> (*testfunc)(data_t *, int, int)) > >> > >>/* cleanup what prepare_crtc() has done */ > >>cleanup_crtc(data, fd, output); > >> - valid_tests++; > >>} > >> +} > >> + > >> +static void crtc_id_subtest(data_t *data, int fd) > >> +{ > >> + igt_display_t *display = >display; > >> + igt_output_t *output; > >> + enum pipe p; > >> + > >> + for_each_pipe_with_valid_output(display, p, output) { > >> + struct drm_event_vblank buf; > >> + const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p); > >> + unsigned crtc_id, expected_crtc_id; > >> + uint64_t val; > >> + union drm_wait_vblank vbl; > >> + > >> + crtc_id = display->pipes[p].crtc_id; > >> + if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, > >> ) == 0) > >> + expected_crtc_id = crtc_id; > >> + else > >> + expected_crtc_id = 0; > >> + > >> + data->pipe = p; > >> + prepare_crtc(data, fd, output); > >> + > >> + memset(, 0, sizeof(vbl)); > >> + vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT; > >> + vbl.request.type |= pipe_id_flag; > >> + vbl.request.sequence = 1; > >> + igt_assert_eq(wait_vblank(fd, ), 0); > >> + > >> + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); > >> + igt_assert_eq(buf.crtc_id, expected_crtc_id); > >> + > >> + do_or_die(drmModePageFlip(fd, crtc_id, > >> +data->primary_fb.fb_id, > >> +DRM_MODE_PAGE_FLIP_EVENT, NULL)); > >> + > >> + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); > >> + igt_assert_eq(buf.crtc_id, expected_crtc_id); > >> + > >> + if (display->is_atomic) { > >> + igt_plane_t *primary = igt_output_get_plane(output, 0); > >> + > >> + igt_plane_set_fb(primary, >primary_fb); > >> + igt_display_commit_atomic(display, > >> DRM_MODE_PAGE_FLIP_EVENT, NULL); > >> > >> - igt_require_f(valid_tests, > >> -"no valid crtc/connector combinations found\n"); > >> + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); > >> + igt_assert_eq(buf.crtc_id, expected_crtc_id); > >> + } > >> + > >> + cleanup_crtc(data, fd, output); > >> + return; > >> + } > >> } > >> > >> static void accuracy(data_t *data, int fd, int nchildren) > >> @@ -307,8 +355,12 @@ igt_main > >>fd = drm_open_driver(DRIVER_ANY); > >>kmstest_set_vt_graphics_mode(); > >>igt_display_init(, fd); > >> + igt_display_require_output(); > >>} > >> > >> + igt_subtest("crtc-id") > >> + crtc_id_subtest(, fd); > > Either I'm stupid, or this doesn't apply on top of latest igt master. > > > > Either way I think taking the expensive modesets out of individual tests > > would be good, so that when we run entire binaries in CI, we'll benefit > > from some good speedup. Which is the plan, now that machines are a bit > > more stable ... > This is my intention of speeding up IGT as well, tests that don't care can use > the inherited pipe/connector. It will speed up testing a lot by preventing > even > performing a modeset. > > I also plan to add a function to read the current state through > igt_display_read_hw_state(), > then find an active pipe/connector, or just the first combination if nothing >
Re: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual
Hi Alexey, Am Freitag, den 24.11.2017, 16:02 + schrieb Alexey Brodkin: > Hello, > > Being in the middle of bring-up of the new board with Vivante GPU (HSDK > namely, > see > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/plat-hsdk) > I was looking at simple 3D test apps to see how Etnaviv works on the hardware. > > So far I was able to get kmscube working perfectly fine and the next item I > took > was glxgears (for some reason I was under impression that's de facto "Hello > world" app > in the GPU world). But apparently even with Xserver up and running glxgears > doesn't work. > > Moreover I tried the same thing on Wandboard Quad but to no avail as well. > That's what I saw: > ->8- > # glxgears > Error: couldn't get an RGB, Double-buffered visual > > # glxinfo > name of display: :0 > Error: couldn't find RGB GLX visual or fbconfig > ->8- > > Googling didn't help here unfortunately so maybe some pointers could be > suggested here... like what do I do wrong and if glxgears is supposed to > work on top of DRM GPU at all? > > Thanks a lot in advance! For 3D acceleration to work under X you need the etnaviv specific DDX driver, which can be found here: http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unstable-devel Don't let you get confused by the name, the armada driver implements support for both armada drm and imx-drm and the etnaviv DDX. This provides 2D acceleration on the Vivante 2D cores, as well a the DRI2/3 bit necessary to get a 3D context on X. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling
On Fri, Nov 24, 2017 at 02:26:09PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/17/2017 6:19 PM, Ville Syrjälä wrote: > > On Fri, Nov 17, 2017 at 05:50:11PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 11/17/2017 5:05 PM, Ville Syrjälä wrote: > >>> On Fri, Nov 17, 2017 at 08:49:49AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/16/2017 9:53 PM, Ville Syrjälä wrote: > > On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 11/13/2017 10:34 PM, Ville Syrjala wrote: > >>> From: Ville Syrjälä> >>> > >>> commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") > >>> cause us to not send out any VICs in the AVI infoframes. That commit > >>> was since reverted, but if and when we add aspect ratio handing back > >>> we need to be more careful. > >>> > >>> Let's handle this by considering the aspect ratio as a requirement > >>> for cea mode matching only if the passed in mode actually has a > >>> non-zero aspect ratio field. This will keep userspace that doesn't > >>> provide an aspect ratio working as before by matching it to the > >>> first otherwise equal cea mode. And once userspace starts to > >>> provide the aspect ratio it will be considerd a hard requirement > >>> for the match. > >>> > >>> Also change the hdmi mode matching to use drm_mode_match() for > >>> consistency, but we don't match on aspect ratio there since the > >>> spec doesn't list a specific aspect ratio for those modes. > >>> > >>> Cc: Shashank Sharma > >>> Cc: "Lin, Jia" > >>> Cc: Akashdeep Sharma > >>> Cc: Jim Bride > >>> Cc: Jose Abreu > >>> Cc: Daniel Vetter > >>> Cc: Emil Velikov > >>> Signed-off-by: Ville Syrjälä > >>> --- > >>> drivers/gpu/drm/drm_edid.c | 18 ++ > >>> 1 file changed, 14 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >>> index 7220b8f9a7e8..00aa98f3e55d 100644 > >>> --- a/drivers/gpu/drm/drm_edid.c > >>> +++ b/drivers/gpu/drm/drm_edid.c > >>> @@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct > >>> drm_display_mode *mode) > >>> static u8 drm_match_cea_mode_clock_tolerance(const struct > >>> drm_display_mode *to_match, > >>>unsigned int > >>> clock_tolerance) > >>> { > >>> + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | > >>> DRM_MODE_MATCH_FLAGS; > >>> u8 vic; > >>> > >>> if (!to_match->clock) > >>> return 0; > >>> > >>> + if (to_match->picture_aspect_ratio) > >>> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; > >> This doesn't look right. This means we are expecting a CEA mode without > >> a pic aspect ratio field, > >> which is invalid. > > No, it's perfectly valid. It's what we currently get from userspace. > Yep, but that's due to missing Aspect ratio handling in the DRM layer. > If that's fixed, as per the list of CEA modes, > each CEA VIC contains an aspect ratio, which is a part of its unique > identity. > > I guess once we have the aspect ratio handling in DRM layer, it > would/should look like this: > - EDID gives you all supported modes, including CEA modes with Aspect > ratio > - Userspcae gets the mode information, with aspect ratio (for CEA modes) > If ( Userspace picks one of the CEA modes) > - sends a modeset > - we find a matching CEA VIC, found one from modedb > - we load this VIC = nonzero information in AVI IF VIC field, > else > - sends a modeset > - we could not find a matching CEA VIC, as aspect ratio is 0 > - we make VIC field in AVI IF as 0 > >>> No. That would break current userspace. > >> I guess I forgot to make it clear, that userspace will set the cap, only > >> then we will provide aspect ratio information. > >> So this should not break userspace, isn't it ? > This is important, as HDMI compliance test 7-27 inspects if the VIC > field in the AVI IF is accurate. > >>> Complicance is secondary to not breaking things that work. Also I find > >>> it hard to see what purpose there is in having a complicance test that > >>> sets a CEA modes w/o aspect ratio and then expects the infoframe to have > >>> VIC 0. > >> Again, typically this is how these analyzers force
Re: [PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle
On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > No functional changes as the code already uses crtc_state->mode > to populate the clip, which is also what drm_mode_get_hv_timing() > uses. I don't understand this explanation, drm_mode_get_hv_timing uses whichever mode is passed to it? > Once everyone agrees on this we can move the clip handling into > drm_atomic_helper_check_plane_state(). I can see that there are no functional changes though, Acked-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/15] drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > Note that this replaces crtc_state->adjusted_mode usage with > crtc_state->mode. The latter is the correct choice since that's the > mode the user provided and it matches the plane crtc coordinates > the user also provided. I am not aware of any adjustments that change hdisplay/vdisplay anyway, Acked-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly
Op 24-11-17 om 16:03 schreef Daniel Vetter: > On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote: >> This was implemented correctly only on the atomic ioctl before, but >> it should really be working on all 3 ioctl's involved, so ensure we >> always set crtc_id correctly with a testcase. >> >> Signed-off-by: Maarten Lankhorst> We seemt to completely lack these checks for the vblank ioctl and the > atomic ioctl too. Can you pls fill these gaps (probably best in kms_flip.c > and kms_atomic.c), too? Summary is a bit out of date, but I did add them in here. :) >> --- >> tests/kms_vblank.c | 60 >> ++ >> 1 file changed, 56 insertions(+), 4 deletions(-) >> >> diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c >> index 47fd10fb9078..004f0e6104ee 100644 >> --- a/tests/kms_vblank.c >> +++ b/tests/kms_vblank.c >> @@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void >> (*testfunc)(data_t *, int, int)) >> igt_display_t *display = >display; >> igt_output_t *output; >> enum pipe p; >> -unsigned int valid_tests = 0; >> >> for_each_pipe_with_valid_output(display, p, output) { >> igt_hang_t hang; >> @@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void >> (*testfunc)(data_t *, int, int)) >> >> /* cleanup what prepare_crtc() has done */ >> cleanup_crtc(data, fd, output); >> -valid_tests++; >> } >> +} >> + >> +static void crtc_id_subtest(data_t *data, int fd) >> +{ >> +igt_display_t *display = >display; >> +igt_output_t *output; >> +enum pipe p; >> + >> +for_each_pipe_with_valid_output(display, p, output) { >> +struct drm_event_vblank buf; >> +const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p); >> +unsigned crtc_id, expected_crtc_id; >> +uint64_t val; >> +union drm_wait_vblank vbl; >> + >> +crtc_id = display->pipes[p].crtc_id; >> +if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, >> ) == 0) >> +expected_crtc_id = crtc_id; >> +else >> +expected_crtc_id = 0; >> + >> +data->pipe = p; >> +prepare_crtc(data, fd, output); >> + >> +memset(, 0, sizeof(vbl)); >> +vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT; >> +vbl.request.type |= pipe_id_flag; >> +vbl.request.sequence = 1; >> +igt_assert_eq(wait_vblank(fd, ), 0); >> + >> +igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); >> +igt_assert_eq(buf.crtc_id, expected_crtc_id); >> + >> +do_or_die(drmModePageFlip(fd, crtc_id, >> + data->primary_fb.fb_id, >> + DRM_MODE_PAGE_FLIP_EVENT, NULL)); >> + >> +igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); >> +igt_assert_eq(buf.crtc_id, expected_crtc_id); >> + >> +if (display->is_atomic) { >> +igt_plane_t *primary = igt_output_get_plane(output, 0); >> + >> +igt_plane_set_fb(primary, >primary_fb); >> +igt_display_commit_atomic(display, >> DRM_MODE_PAGE_FLIP_EVENT, NULL); >> >> -igt_require_f(valid_tests, >> - "no valid crtc/connector combinations found\n"); >> +igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); >> +igt_assert_eq(buf.crtc_id, expected_crtc_id); >> +} >> + >> +cleanup_crtc(data, fd, output); >> +return; >> +} >> } >> >> static void accuracy(data_t *data, int fd, int nchildren) >> @@ -307,8 +355,12 @@ igt_main >> fd = drm_open_driver(DRIVER_ANY); >> kmstest_set_vt_graphics_mode(); >> igt_display_init(, fd); >> +igt_display_require_output(); >> } >> >> +igt_subtest("crtc-id") >> +crtc_id_subtest(, fd); > Either I'm stupid, or this doesn't apply on top of latest igt master. > > Either way I think taking the expensive modesets out of individual tests > would be good, so that when we run entire binaries in CI, we'll benefit > from some good speedup. Which is the plan, now that machines are a bit > more stable ... This is my intention of speeding up IGT as well, tests that don't care can use the inherited pipe/connector. It will speed up testing a lot by preventing even performing a modeset. I also plan to add a function to read the current state through igt_display_read_hw_state(), then find an active pipe/connector, or just the first combination if nothing matches. And after the end of the test keep it alive without disabling the crtc's, only removing framebuffers, which no longer disables the crtc's on i915. :-) ~Maarten
[Bug 103791] Tearing after screen wakeup/on
https://bugs.freedesktop.org/show_bug.cgi?id=103791 --- Comment #5 from denisgolo...@yandex.ru --- (In reply to Michel Dänzer from comment #4) > We need to find out why the kernel starts returning -EINVAL from the page > flip and wait for vblank ioctls. > > Can you try writing 255 to /sys/module/drm/parameters/debug before > reproducing the problem, and attach the resulting dmesg output? (Note that > writing non-0 to /sys/module/drm/parameters/debug will cause a lot of > debugging output to be generated, so you'll want to write 0 to it again soon > afterwards) Got it. I'll attach dmesg as soon as I reproduce the issue. > In case that doesn't reveal why -EINVAL is being returned, are you able to > recompile the drm.ko / amdgpu.ko kernel modules with a patch applied? Sure. Gentoo is there :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: adapt to new TTM interface
On Fri, Nov 24, 2017 at 01:53:16PM +0100, Christian König wrote: > Am 24.11.2017 um 11:37 schrieb Greg KH: > > On Fri, Nov 24, 2017 at 11:32:59AM +0100, Christian König wrote: > > > Fixes interface changes done in the following commits: > > > drm/ttm: add operation ctx to ttm_bo_validate v2 > > > drm/ttm: add context to driver move callback as well > > Any hints on the git commit ids in Linus's tree? > > Those haven't arrived in Linus tree yet. > > > And does this mean the driver's build is now broken? > > Yes, it broke the build. Sorry that was my fault, didn't had this staging > driver activated in the config nor noticed that there is an user of ttm > outside the drm directory. > > > Should this go through the staging tree, or is it to go through the drm > > tree? > > The DRM tree I think. We should probably squash this patch into the original > change which broke the driver in the DRM tree. That's fine with me, thanks for the patch: Acked-by: Greg Kroah-Hartman___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in TTM driver w/Linus' master
On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: > > On 11/23/17 2:58 AM, Dave Airlie wrote: > > On 23 November 2017 at 11:17, Laura Abbottwrote: > > > Hi, > > > > > > Fedora QA testing reported a panic when booting up VMs > > > using qmeu vga drivers > > > (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ) > > > > > > [ 30.108507] [ cut here ] > > > [ 30.108920] kernel BUG at ./include/linux/gfp.h:408! > > > [ 30.109356] invalid opcode: [#1] SMP > > > [ 30.109700] Modules linked in: fuse nf_conntrack_netbios_ns > > > nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 > > > xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge > > > ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle > > > ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 > > > nf_defrag_ipv4 > > > nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw > > > iptable_security ebtable_filter ebtables ip6table_filter ip6_tables > > > snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass > > > ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm > > > joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm > > > soundcore > > > parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q > > > garp > > > mrp stp llc virtio_net > > > [ 30.115605] virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul > > > crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio > > > ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop > > > [ 30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted > > > 4.15.0-0.rc0.git6.1.fc28.x86_64 #1 > > > [ 30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > > 1.10.2-2.fc27 04/01/2014 > > > [ 30.118866] task: 923a77e03380 task.stack: a78182228000 > > > [ 30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430 > > > [ 30.119810] RSP: :a7818222bba8 EFLAGS: 00010202 > > > [ 30.120250] RAX: 0001 RBX: 014382c6 RCX: > > > 0006 > > > [ 30.120840] RDX: RSI: 0009 RDI: > > > > > > [ 30.121443] RBP: 923a760d6000 R08: R09: > > > 0006 > > > [ 30.122039] R10: 0040 R11: 0300 R12: > > > 923a729273c0 > > > [ 30.122629] R13: R14: R15: > > > 923a7483d400 > > > [ 30.123223] FS: 7fe48da7dac0() GS:923a7cc0() > > > knlGS: > > > [ 30.123896] CS: 0010 DS: ES: CR0: 80050033 > > > [ 30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: > > > 06f0 > > > [ 30.124968] Call Trace: > > > [ 30.125186] ttm_pool_populate+0x19b/0x400 [ttm] > > > [ 30.125578] ttm_bo_vm_fault+0x325/0x570 [ttm] > > > [ 30.125964] __do_fault+0x19/0x11e > > > [ 30.126255] __handle_mm_fault+0xcd3/0x1260 > > > [ 30.126609] handle_mm_fault+0x14c/0x310 > > > [ 30.126947] __do_page_fault+0x28c/0x530 > > > [ 30.127282] do_page_fault+0x32/0x270 > > > [ 30.127593] async_page_fault+0x22/0x30 > > > [ 30.127922] RIP: 0033:0x7fe48aae39a8 > > > [ 30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206 > > > [ 30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: > > > 7fe457b73040 > > > [ 30.129259] RDX: 0030 RSI: RDI: > > > 7fe457b73000 > > > [ 30.129855] RBP: 0300 R08: 000c R09: > > > 0001 > > > [ 30.130457] R10: 0001 R11: 0246 R12: > > > 55cd4c1041a0 > > > [ 30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: > > > 0400 > > > [ 30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f > > > ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff > > > <0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c > > > [ 30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: > > > a7818222bba8 > > > [ 30.133836] ---[ end trace d4f1deb60784f40a ]--- > > > > > > This is based off of Linus' master branch at > > > c8a0739b185d11d6e2ca7ad9f5835841d1cfc765 > > > Configs are at > > > https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 > > > > > Looks like a TTM regression due to: > > > > 0284f1ead87463bc17cf5e81a24fc65c052486f3 > > drm/ttm: add transparent huge page support for cached allocations v2 > > > > If the driver requests dma32 pages, we can end up trying to alloc huge > > dma32 pages which triggers the oops. The bochs driver always requests > > dma32 here. > > > > I'll send a rough patch once I boot it. > > > > Dave. > > > Hi Dave, > > fyi only: It looks like this is not the only regression in this cycle with >
Re: [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly
On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote: > This was implemented correctly only on the atomic ioctl before, but > it should really be working on all 3 ioctl's involved, so ensure we > always set crtc_id correctly with a testcase. > > Signed-off-by: Maarten LankhorstWe seemt to completely lack these checks for the vblank ioctl and the atomic ioctl too. Can you pls fill these gaps (probably best in kms_flip.c and kms_atomic.c), too? > --- > tests/kms_vblank.c | 60 > ++ > 1 file changed, 56 insertions(+), 4 deletions(-) > > diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c > index 47fd10fb9078..004f0e6104ee 100644 > --- a/tests/kms_vblank.c > +++ b/tests/kms_vblank.c > @@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void > (*testfunc)(data_t *, int, int)) > igt_display_t *display = >display; > igt_output_t *output; > enum pipe p; > - unsigned int valid_tests = 0; > > for_each_pipe_with_valid_output(display, p, output) { > igt_hang_t hang; > @@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void > (*testfunc)(data_t *, int, int)) > > /* cleanup what prepare_crtc() has done */ > cleanup_crtc(data, fd, output); > - valid_tests++; > } > +} > + > +static void crtc_id_subtest(data_t *data, int fd) > +{ > + igt_display_t *display = >display; > + igt_output_t *output; > + enum pipe p; > + > + for_each_pipe_with_valid_output(display, p, output) { > + struct drm_event_vblank buf; > + const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p); > + unsigned crtc_id, expected_crtc_id; > + uint64_t val; > + union drm_wait_vblank vbl; > + > + crtc_id = display->pipes[p].crtc_id; > + if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, > ) == 0) > + expected_crtc_id = crtc_id; > + else > + expected_crtc_id = 0; > + > + data->pipe = p; > + prepare_crtc(data, fd, output); > + > + memset(, 0, sizeof(vbl)); > + vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT; > + vbl.request.type |= pipe_id_flag; > + vbl.request.sequence = 1; > + igt_assert_eq(wait_vblank(fd, ), 0); > + > + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); > + igt_assert_eq(buf.crtc_id, expected_crtc_id); > + > + do_or_die(drmModePageFlip(fd, crtc_id, > + data->primary_fb.fb_id, > + DRM_MODE_PAGE_FLIP_EVENT, NULL)); > + > + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); > + igt_assert_eq(buf.crtc_id, expected_crtc_id); > + > + if (display->is_atomic) { > + igt_plane_t *primary = igt_output_get_plane(output, 0); > + > + igt_plane_set_fb(primary, >primary_fb); > + igt_display_commit_atomic(display, > DRM_MODE_PAGE_FLIP_EVENT, NULL); > > - igt_require_f(valid_tests, > - "no valid crtc/connector combinations found\n"); > + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf)); > + igt_assert_eq(buf.crtc_id, expected_crtc_id); > + } > + > + cleanup_crtc(data, fd, output); > + return; > + } > } > > static void accuracy(data_t *data, int fd, int nchildren) > @@ -307,8 +355,12 @@ igt_main > fd = drm_open_driver(DRIVER_ANY); > kmstest_set_vt_graphics_mode(); > igt_display_init(, fd); > + igt_display_require_output(); > } > > + igt_subtest("crtc-id") > + crtc_id_subtest(, fd); Either I'm stupid, or this doesn't apply on top of latest igt master. Either way I think taking the expensive modesets out of individual tests would be good, so that when we run entire binaries in CI, we'll benefit from some good speedup. Which is the plan, now that machines are a bit more stable ... -Daniel > + > for (f = funcs; f->name; f++) { > for (m = modes; m->name; m++) { > if (m->flags & ~f->valid) > -- > 2.15.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
On Fri, Nov 24, 2017 at 04:08:28PM +0200, Ville Syrjälä wrote: > On Fri, Nov 24, 2017 at 11:59:45AM +, Liviu Dudau wrote: > > On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä> > > > Hi Ville, > > > > > > > > Move the plane clip rectangle handling into > > > drm_atomic_helper_check_plane_state(). Drivers no longer > > > have to worry about such mundane details. > > > > This is quite an important patch and I dare say the essence of your > > series, right? Yet very few people got Cc-ed on it (1 AFAICT) and it > > touches quite a few drivers. > > It has no functional changes, so forgetting to plaster it with Ccs > doesn't seem all that dangerous. All the (potentially) functional > changes were in the prep patches which had Ccs, as did the cover > letter. And maintainers should read the ml anyway ;) Maintainers don't maintain the functionality, they maintain the source code. They fix conflicts and order patches. On that line, not Cc-ing maintainers when you change the code of the drivers they maintain makes their lives all more ... "entertaining". And I would argue that the patch does introduce functional changes, as it removes the clip rectangle from drm_atomic_helper_check_plane_state()'s list of parameters. It does change all the users of it, too, I agree, but not for people that have drivers not yet upstreamed (and they start to wonder how one driver compiles and other fails when they were supposed to have the same code inside :) ) Regards, Liviu > > -- > Ville Syrjälä > Intel OTC -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes
On Fri, Nov 24, 2017 at 8:38 AM, Ville Syrjäläwrote: > On Thu, Nov 23, 2017 at 03:14:46PM -0500, Ilia Mirkin wrote: >> On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä >> wrote: >> > On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote: >> >> We need to shift the values up, otherwise we'd end up with a negative >> >> shift. This works for up-to 16-bit components, which is fine for now. >> > >> > Shouldn't we actually replicate the high bits in the low bits? >> >> Not entirely sure what you're proposing... >> >> Ideally we wouldn't be lazy and pass e.g. 16-bit values to MAKE_RGBA >> which would then shift down as necessary (and even there, you could >> end up with off-by-1's maybe?). For e.g. 0xff, that should become >> 0x3ff but with my code will become 0x3fc. > > Exactly the issue. > >> But for other values, it's >> less clear what to do with the low bits. I figured it didn't really >> matter. >> >> Do you have a concrete proposal? > > The usual thing would be just > > (value) * 0x3ff / 0xff > > or > > ((value) << 2) | ((value) >> 6) The latter method is interesting, it slowly biases from rounding down to rounding up as you go through the range. Clever. I guess I could change my function to use (value << 8) | value and then use that to shift around. I'll send a v2. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103791] Tearing after screen wakeup/on
https://bugs.freedesktop.org/show_bug.cgi?id=103791 --- Comment #4 from Michel Dänzer--- We need to find out why the kernel starts returning -EINVAL from the page flip and wait for vblank ioctls. Can you try writing 255 to /sys/module/drm/parameters/debug before reproducing the problem, and attach the resulting dmesg output? (Note that writing non-0 to /sys/module/drm/parameters/debug will cause a lot of debugging output to be generated, so you'll want to write 0 to it again soon afterwards) In case that doesn't reveal why -EINVAL is being returned, are you able to recompile the drm.ko / amdgpu.ko kernel modules with a patch applied? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REBASE 3/5] drm: Expose modes with aspect ratio, only if requested
On Fri, Nov 24, 2017 at 02:36:17PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/21/2017 10:41 PM, Ville Syrjälä wrote: > > On Fri, Nov 17, 2017 at 03:00:30PM +0530, Shashank Sharma wrote: > >> From: aknautiy> >> > >> We parse the EDID and add all the modes in the connector's > >> modelist. This adds CEA modes with aspect ratio information > >> too, regadless of if user space requested this information or > >> not. > >> > >> This patch prunes the modes with aspect-ratio information, from > >> a connector's modelist, if the user-space has not set the aspect > >> ratio DRM client cap. > >> > >> Cc: Ville Syrjala > >> Cc: Shashank Sharma > >> Cc: Jose Abreu > >> > >> Signed-off-by: aknautiy > >> --- > >> drivers/gpu/drm/drm_connector.c | 7 +++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/drm_connector.c > >> b/drivers/gpu/drm/drm_connector.c > >> index 704fc89..a246bb5 100644 > >> --- a/drivers/gpu/drm/drm_connector.c > >> +++ b/drivers/gpu/drm/drm_connector.c > >> @@ -1285,6 +1285,13 @@ static bool drm_mode_expose_to_userspace(const > >> struct drm_display_mode *mode, > >> */ > >>if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode)) > >>return false; > >> + /* > >> + * If user-space hasn't configured the driver to expose the modes > >> + * with aspect-ratio, don't expose them. > >> + */ > >> + if (!file_priv->aspect_ratio_allowed && > >> + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) > >> + return false; > > I don't think we can just blindly drop the modes. We would have to > > expose them with the aspect ratio cleared. That could lead to > > duplicates, but I'm thinking that shouldn't be a real problem for > > userspace. Having to filteri out the duplicates would certainly > > complicate things a bit. > Yes, Agree. Even I was thinking that the right way should be to: > - add a drm_mode_equal_no_aspect function (like > drm_mode_equal_no_clock_no_stereo). Or just drm_mode_match() with the right flags ;) > - clear the aspect ratio information from the mode, when not asked for. > - check the sorted connector->modes list for duplicates for this mode, > using above function. > - if mode exists, remove it from the list > - if not, keep it in the list Hmm. Since the list should be sorted I guess this won't even have to traverse the list mutliple times. We can just keep skipping modes as long they match the last mode we've already decided to expose. > > Sounds like a plan ? > > - Shashank > >> > >>return true; > >> } > >> -- > >> 2.7.4 -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: add clut mode support
Hi Peter, On 11/13/2017 11:40 AM, Philippe CORNU wrote: > Hi Peter, > > On 11/12/2017 01:31 PM, Peter Rosin wrote: >> On 2017-11-10 17:12, Philippe CORNU wrote: >>> Hi Peter, >>> >>> On 11/07/2017 05:34 PM, Peter Rosin wrote: On 2017-11-07 16:53, Philippe CORNU wrote: > + Peter > > Hi Peter, > > CLUT support on STM32 has been removed thanks to your clean up patch Support is a bit strong for what I thought was a dead function, or are you saying that it used to work before my series? Really sorry if that is the case! >>> >>> As I wrote in the previous related thread >>> (https://lists.freedesktop.org/archives/dri-devel/2017-June/145070.html), >>> >>> STM32 chipsets supports 8-bit CLUT mode but this driver version does not >>> support it "yet"... >>> >>> So, no worry regarding your clean up, I gave you an "acked-by" for >>> that : ) >> >> Ok, good. Thanks for clearing that up! >> Anyway, the function I removed seemed to indicate that the hardware could handle a separate clut for each layer, but your new version does not. Why is that? >>> >>> Yes I confirm the clut support is available for each layer... but I >>> thought the gamma_lut was only at the crtc level, not at layer level... >>> Maybe I am wrong. >>> Moreover, small test applications I used play only with clut at crtc >>> level... >>> >>> Anyway, could you please help me to "find" a per-layer clut >>> implementation because when I read "crtc->state->gamma_lut->data" it >>> looks like gamma_lut is per crtc, not per plane...? or maybe I have to >>> add extra properties for that... >> >> I wasn't clear enough. Yes, there is to my knowledge only one clut, >> not one per plane. What I noticed was that the function I removed >> seemed to touch clut registers for multiple layers, but your new >> function appears to only touch registers for one layer. So, I >> wondered if the "one and only" clut needed to be copied to the >> registers for the other layers, or if the old dead code was simply >> confused. Clearer? >> > > The old code was a generic helper function (ie. for all layers) but used > only for the 1st layer. So, we could say that "old dead code was simply > confused" :-) > > When I put back the clut support in this patch, I decided to update only > the 1st layer (because there is no API for handling it on other layers). > I also decided to not re-use the former generic helper function as the > update loop is pretty small. > > This patch offers the clut mode feature for fbdev (only one plane in > fbdev) and for drm (single plane for many use cases, 2nd plane being > used mostly for video...) > > If tomorrow the API offers clut support per plane, the update loop will > be moved to the plane update function, means the generic helper function > will not be require anymore too. From the explanations above, do you think the patch is "acceptable" or should I change it somehow? What is your opinion? Many thanks, Philippe :-) > > Many thanks > Philippe :) > >> Cheers. >> Peter >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in TTM driver w/Linus' master
Am 24.11.2017 um 16:17 schrieb Tobias Klausmann: On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbottwrote: Hi, Fedora QA testing reported a panic when booting up VMs using qmeu vga drivers (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ) [ 30.108507] [ cut here ] [ 30.108920] kernel BUG at ./include/linux/gfp.h:408! [ 30.109356] invalid opcode: [#1] SMP [ 30.109700] Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc virtio_net [ 30.115605] virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop [ 30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 4.15.0-0.rc0.git6.1.fc28.x86_64 #1 [ 30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 30.118866] task: 923a77e03380 task.stack: a78182228000 [ 30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430 [ 30.119810] RSP: :a7818222bba8 EFLAGS: 00010202 [ 30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006 [ 30.120840] RDX: RSI: 0009 RDI: [ 30.121443] RBP: 923a760d6000 R08: R09: 0006 [ 30.122039] R10: 0040 R11: 0300 R12: 923a729273c0 [ 30.122629] R13: R14: R15: 923a7483d400 [ 30.123223] FS: 7fe48da7dac0() GS:923a7cc0() knlGS: [ 30.123896] CS: 0010 DS: ES: CR0: 80050033 [ 30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0 [ 30.124968] Call Trace: [ 30.125186] ttm_pool_populate+0x19b/0x400 [ttm] [ 30.125578] ttm_bo_vm_fault+0x325/0x570 [ttm] [ 30.125964] __do_fault+0x19/0x11e [ 30.126255] __handle_mm_fault+0xcd3/0x1260 [ 30.126609] handle_mm_fault+0x14c/0x310 [ 30.126947] __do_page_fault+0x28c/0x530 [ 30.127282] do_page_fault+0x32/0x270 [ 30.127593] async_page_fault+0x22/0x30 [ 30.127922] RIP: 0033:0x7fe48aae39a8 [ 30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206 [ 30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040 [ 30.129259] RDX: 0030 RSI: RDI: 7fe457b73000 [ 30.129855] RBP: 0300 R08: 000c R09: 0001 [ 30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0 [ 30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400 [ 30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c [ 30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8 [ 30.133836] ---[ end trace d4f1deb60784f40a ]--- This is based off of Linus' master branch at c8a0739b185d11d6e2ca7ad9f5835841d1cfc765 Configs are at https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 Looks like a TTM regression due to: 0284f1ead87463bc17cf5e81a24fc65c052486f3 drm/ttm: add transparent huge page support for cached allocations v2 If the driver requests dma32 pages, we can end up trying to alloc huge dma32 pages which triggers the oops. The bochs driver always requests dma32 here. I'll send a rough patch once I boot it. Dave. Hi Dave, fyi only: It looks like this is not the only regression in this cycle with ttm, novueau seems to suffer as well [1]. Adding ttm folks. Might be useful if we have an entry for ttm in MAINTAINERS ... -Daniel A bit more of investigation for the nouveau regression: This only show when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are enable. Thanks Dave for pointing me to that! Yeah, sorry for that. I missed to handle the DMA32 case with transparent huge page support. Dave already came up with a fix
Re: [PATCH v2] drm/atomic: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in error paths
On Wed, Nov 15, 2017 at 08:38:41PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares > about. However error paths everyone cares about, so hiding thea error > debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS > for those instead. Actually, one idea that came to my mind right now is that maybe we want to keep using _ATOMIC with TEST_ONLY, and only use _KMS w/o TEST_ONLY? > > v2: Rebase and handle a few new cases > > Cc: Jani Nikula > Reviewed-by: Jani Nikula #v1 > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_atomic.c| 64 - > drivers/gpu/drm/drm_atomic_helper.c | 70 > ++--- > 2 files changed, 66 insertions(+), 68 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 37445d50816a..594bdd5c33cb 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -572,8 +572,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc, >*/ > > if (state->active && !state->enable) { > - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n", > - crtc->base.id, crtc->name); > + DRM_DEBUG_KMS("[CRTC:%d:%s] active without enabled\n", > + crtc->base.id, crtc->name); > return -EINVAL; > } > > @@ -582,15 +582,15 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc, >* be able to trigger. */ > if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) && > WARN_ON(state->enable && !state->mode_blob)) { > - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n", > - crtc->base.id, crtc->name); > + DRM_DEBUG_KMS("[CRTC:%d:%s] enabled without mode blob\n", > + crtc->base.id, crtc->name); > return -EINVAL; > } > > if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) && > WARN_ON(!state->enable && state->mode_blob)) { > - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n", > - crtc->base.id, crtc->name); > + DRM_DEBUG_KMS("[CRTC:%d:%s] disabled with mode blob\n", > + crtc->base.id, crtc->name); > return -EINVAL; > } > > @@ -605,8 +605,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc, >* pipe. >*/ > if (state->event && !state->active && !crtc->state->active) { > - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n", > - crtc->base.id, crtc->name); > + DRM_DEBUG_KMS("[CRTC:%d:%s] requesting event but off\n", > + crtc->base.id, crtc->name); > return -EINVAL; > } > > @@ -861,10 +861,10 @@ static int drm_atomic_plane_check(struct drm_plane > *plane, > > /* either *both* CRTC and FB must be set, or neither */ > if (WARN_ON(state->crtc && !state->fb)) { > - DRM_DEBUG_ATOMIC("CRTC set but no FB\n"); > + DRM_DEBUG_KMS("CRTC set but no FB\n"); > return -EINVAL; > } else if (WARN_ON(state->fb && !state->crtc)) { > - DRM_DEBUG_ATOMIC("FB set but no CRTC\n"); > + DRM_DEBUG_KMS("FB set but no CRTC\n"); > return -EINVAL; > } > > @@ -874,7 +874,7 @@ static int drm_atomic_plane_check(struct drm_plane *plane, > > /* Check whether this plane is usable on this CRTC */ > if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) { > - DRM_DEBUG_ATOMIC("Invalid crtc for plane\n"); > + DRM_DEBUG_KMS("Invalid crtc for plane\n"); > return -EINVAL; > } > > @@ -882,9 +882,9 @@ static int drm_atomic_plane_check(struct drm_plane *plane, > ret = drm_plane_check_pixel_format(plane, state->fb->format->format); > if (ret) { > struct drm_format_name_buf format_name; > - DRM_DEBUG_ATOMIC("Invalid pixel format %s\n", > - drm_get_format_name(state->fb->format->format, > - _name)); > + DRM_DEBUG_KMS("Invalid pixel format %s\n", > + drm_get_format_name(state->fb->format->format, > + _name)); > return ret; > } > > @@ -893,9 +893,9 @@ static int drm_atomic_plane_check(struct drm_plane *plane, > state->crtc_x > INT_MAX - (int32_t) state->crtc_w || > state->crtc_h > INT_MAX || > state->crtc_y > INT_MAX - (int32_t) state->crtc_h) { > - DRM_DEBUG_ATOMIC("Invalid CRTC coordinates
[GIT PULL] mali-dp: fixes for drm-next
Hi Dave, This is the queue of patches I have for mali-dp tree. They have been in linux-next for a few weeks without issues. Please pull. Many thanks, Liviu The following changes since commit c209101fc1c91a318422733a3721ff6a9ff7899f: Merge tag 'drm-misc-fixes-2017-11-20' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-24 11:33:29 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/mali-dp for you to fetch changes up to 54243016ae35a0912a680f884835237fd6176820: drm: mali-dp: Disable planes when their CRTC gets disabled. (2017-11-24 15:43:52 +) Cihangir Akturk (1): drm: mali-dp: switch to drm_*_get(), drm_*_put() helpers Liviu Dudau (2): drm: mali-dp: Separate static internal data into a read-only structure. drm: mali-dp: Disable planes when their CRTC gets disabled. Srishti Sharma (1): drm/arm: Replace instances of drm_dev_unref with drm_dev_put. drivers/gpu/drm/arm/malidp_crtc.c | 16 + drivers/gpu/drm/arm/malidp_drv.c| 34 +-- drivers/gpu/drm/arm/malidp_hw.c | 46 ++ drivers/gpu/drm/arm/malidp_hw.h | 65 ++--- drivers/gpu/drm/arm/malidp_planes.c | 21 ++-- 5 files changed, 99 insertions(+), 83 deletions(-) -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=102800 --- Comment #15 from higu...@gmx.net --- no, the with the pcie_port_pm=force and 4.14.0, it still fails -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103783] atombios stuck in loop for more than 5secs
https://bugs.freedesktop.org/show_bug.cgi?id=103783 --- Comment #8 from Rene Barbosa--- vkr...@yahoo.com, Are you using TLP or something similar? I ran some tests and found that's only happening when using TLP. Tried with Ubuntu 17.10 and Fedora 27, same results. Regards, Rene Barbosa -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in TTM driver w/Linus' master
Am 24.11.2017 um 17:29 schrieb Tobias Klausmann: On 11/24/17 4:35 PM, Christian König wrote: Am 24.11.2017 um 16:17 schrieb Tobias Klausmann: On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbottwrote: Hi, Fedora QA testing reported a panic when booting up VMs using qmeu vga drivers (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ) [ 30.108507] [ cut here ] [ 30.108920] kernel BUG at ./include/linux/gfp.h:408! [ 30.109356] invalid opcode: [#1] SMP [ 30.109700] Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc virtio_net [ 30.115605] virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop [ 30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 4.15.0-0.rc0.git6.1.fc28.x86_64 #1 [ 30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 30.118866] task: 923a77e03380 task.stack: a78182228000 [ 30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430 [ 30.119810] RSP: :a7818222bba8 EFLAGS: 00010202 [ 30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006 [ 30.120840] RDX: RSI: 0009 RDI: [ 30.121443] RBP: 923a760d6000 R08: R09: 0006 [ 30.122039] R10: 0040 R11: 0300 R12: 923a729273c0 [ 30.122629] R13: R14: R15: 923a7483d400 [ 30.123223] FS: 7fe48da7dac0() GS:923a7cc0() knlGS: [ 30.123896] CS: 0010 DS: ES: CR0: 80050033 [ 30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0 [ 30.124968] Call Trace: [ 30.125186] ttm_pool_populate+0x19b/0x400 [ttm] [ 30.125578] ttm_bo_vm_fault+0x325/0x570 [ttm] [ 30.125964] __do_fault+0x19/0x11e [ 30.126255] __handle_mm_fault+0xcd3/0x1260 [ 30.126609] handle_mm_fault+0x14c/0x310 [ 30.126947] __do_page_fault+0x28c/0x530 [ 30.127282] do_page_fault+0x32/0x270 [ 30.127593] async_page_fault+0x22/0x30 [ 30.127922] RIP: 0033:0x7fe48aae39a8 [ 30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206 [ 30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040 [ 30.129259] RDX: 0030 RSI: RDI: 7fe457b73000 [ 30.129855] RBP: 0300 R08: 000c R09: 0001 [ 30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0 [ 30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400 [ 30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c [ 30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8 [ 30.133836] ---[ end trace d4f1deb60784f40a ]--- This is based off of Linus' master branch at c8a0739b185d11d6e2ca7ad9f5835841d1cfc765 Configs are at https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 Looks like a TTM regression due to: 0284f1ead87463bc17cf5e81a24fc65c052486f3 drm/ttm: add transparent huge page support for cached allocations v2 If the driver requests dma32 pages, we can end up trying to alloc huge dma32 pages which triggers the oops. The bochs driver always requests dma32 here. I'll send a rough patch once I boot it. Dave. Hi Dave, fyi only: It looks like this is not the only regression in this cycle with ttm, novueau seems to suffer as well [1]. Adding ttm folks. Might be useful if we have an entry for ttm in MAINTAINERS ... -Daniel A bit more of investigation for the nouveau regression: This only show when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are enable. Thanks Dave for pointing me to that! Yeah, sorry for that. I
Re: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual
Am Freitag, den 24.11.2017, 16:49 + schrieb Alexey Brodkin: [...] > > Yes, a "core" in Vivante speak is a GPU with one DMA frontend. A > > single > > frontend can feed both 3D and 2D acceleration engines behind it. On > > i.MX6 the 2D and 3D engine are on separate cores, but Marvell Dove > > has > > a combined 2D/3D core. > > Hm, that sounds encouraging. The next question would be if Marvel > Dove is > supported in Etnaviv DDX? I guess it's called Armada so the answer if > yes, right? Yes, the Dove was the original platform for the Armada X.Org driver. Combined 2D/3D cores are supported just fine by etnaviv. > > > If we happen to not have 2D core if that's a no go for us for > > > anything? > > > > I don't know if the DDX works properly without 2D acceleration. > > Weston > > on the other hand only relies on the 3D accel core for doing > > compositing, so even if you don't have a 2D engine you will be able > > to > > launch a modern Linux graphics stack. > > That's really cool! I'm much more interested in Weston ATM, which is > actually another separate question :) > I tried to find some details on how to run Weston on Wandboard > but seems like I was looking at wrong Google again... do you > know any good manuals for doing that? There really is no magic to it. Or better there is, but it's all hidden in the Mesa implementation. You need at least Mesa 17.2 and Weston 3.0 for etnaviv to work properly. Other than that just set XDG_RUNTIME_DIR to something sensible and launch Weston with "weston --tty=63", done. > > > > The etnaviv DDX could also emulate 2D accel over the 3D core by > > using > > the X.Org glamor module, but no one has bothered to implement this > > yet. > > Ok we'll see if above case (combined cores) is applicable to us and > then > we'll see what to do. > > > > In the meantime I'll try to figure out if we have 2D core or not. > > > > You can find out what your GPU provides by looking at the feature > > bits. > > chipFeatures_PIPE_2D, chipFeatures_PIPE_3D and chipFeatures_PIPE_VG > > is > > what you are looking out for. > > Does that info helps to decipher these bits? Unfortunately we forgot to expose the major feature bits register in debugfs. It's gpu->identity.features in the kernel driver, the interesting bits in there are chipFeatures_PIPE_3D and chipFeatures_PIPE_2D. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
On Fri, Nov 24, 2017 at 2:08 PM, Christian Zigotzkywrote: > On 24.11.2017 17:09, Michel Dänzer wrote: >> >> On 2017-11-24 03:29 PM, Christian Zigotzky wrote: >>> >>> Hi All, >>> >>> I bisected today and the first bad commit is: >>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions >>> to populate/map in one call (v2)) [1] >> >> It can't really be that commit, since it just adds functions but doesn't >> hook them up anywhere. Presumably it's commit >> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM >> populate/dma map helper functions") instead, which makes the radeon >> driver rely on ttm_populate_and_map_pages, which is just a stub >> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is >> enabled. >> >> I can see two possible solutions: >> >> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages >> work without SWIOTLB / INTEL_IOMMU as well. >> >> 2. Make the drivers work without ttm_populate_and_map_pages and >> ttm_unmap_and_unpopulate_pages again in that case. >> >> >> Solution 1 would be preferable. >> >> > Hello Michel, > > I tested the latest git version today. Unfortunately the problem with the > hardware 3D acceleration still exist. How can I make > ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without > SWIOTLB / INTEL_IOMMU? Do you have SWIOTLB disabled in your .config? Try enabling it to see if that's the issue. Looking at your bisect log, you might have incorrectly marked some revisions. E.g. you had a compile failure, which while isn't "good", it's also not "bad" -- good and bad are only in reference to the specific issue you're seeing. In such cases you can run "git bisect skip" which will mark the commit as "unknown" and pick a different one to try. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
On 24.11.2017 20:08, Christian Zigotzky wrote: On 24.11.2017 17:09, Michel Dänzer wrote: On 2017-11-24 03:29 PM, Christian Zigotzky wrote: Hi All, I bisected today and the first bad commit is: a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions to populate/map in one call (v2)) [1] It can't really be that commit, since it just adds functions but doesn't hook them up anywhere. Presumably it's commit f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM populate/dma map helper functions") instead, which makes the radeon driver rely on ttm_populate_and_map_pages, which is just a stub returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled. I can see two possible solutions: 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without SWIOTLB / INTEL_IOMMU as well. 2. Make the drivers work without ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages again in that case. Solution 1 would be preferable. Hello Michel, I tested the latest git version today. Unfortunately the problem with the hardware 3D acceleration still exist. How can I make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without SWIOTLB / INTEL_IOMMU? Thanks, Christian Just for info: CONFIG_SWIOTLB is not set and CONFIG_PPC_PASEMI_IOMMU is enabled. -- Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver
https://bugs.freedesktop.org/show_bug.cgi?id=92827 --- Comment #5 from Michael Zapf--- I just got kernel 4.14, but I still don't have any audio output via HDMI. Is that supposed to work by now? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103814] incorrect dust rendering in hl2 without sisched
https://bugs.freedesktop.org/show_bug.cgi?id=103814 Hleb Valoshka <375...@gmail.com> changed: What|Removed |Added Summary|incorrect dust rendering in |incorrect dust rendering in |hl2ep1 without some |hl2 without sisched |R600_DEBUG options | QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org --- Comment #2 from Hleb Valoshka <375...@gmail.com> --- I've tested other HL2 titles (HL2, EP2, Lost Coast), they all have this issue. But it can be workarounded by usage of sisched. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 01/15] drm/i915: Reject odd pipe source width with double wide/dual link
On Thu, Nov 23, 2017 at 09:04:48PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä> > In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay > we must not adjust pipe_src_w to accommodate double wide/dual link. > Instead just reject the mode outright. > > This will allows us to rely on crtc_state->mode for plane clipping. > > Cc: Laurent Pinchart > Signed-off-by: Ville Syrjälä Might be real good if we have some igt that injects all these kinds of funny modes, just to check for bugs and stuff (i.e. not encoding any expectations that any of them work). Or maybe we need a smart fuzzer for the atomic ioctl for that. Musings aside, on patches 1&2: Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_display.c | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index d67c7c498b34..959d21157328 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6332,9 +6332,18 @@ static int intel_crtc_compute_config(struct intel_crtc > *crtc, >* - LVDS dual channel mode >* - Double wide pipe >*/ > - if ((intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) && > - intel_is_dual_link_lvds(dev)) || pipe_config->double_wide) > - pipe_config->pipe_src_w &= ~1; > + if (pipe_config->pipe_src_w & 1) { > + if (pipe_config->double_wide) { > + DRM_DEBUG_KMS("Odd pipe source width not supported with > double wide pipe\n"); > + return -EINVAL; > + } > + > + if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) && > + intel_is_dual_link_lvds(dev)) { > + DRM_DEBUG_KMS("Odd pipe source width not supported with > dual link LVDS\n"); > + return -EINVAL; > + } > + } > > /* Cantiga+ cannot handle modes with a hsync front porch of 0. >* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw. > -- > 2.13.6 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hardware 3D acceleration doesn't work anymore with the latest git kernel
On 24.11.2017 17:09, Michel Dänzer wrote: On 2017-11-24 03:29 PM, Christian Zigotzky wrote: Hi All, I bisected today and the first bad commit is: a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions to populate/map in one call (v2)) [1] It can't really be that commit, since it just adds functions but doesn't hook them up anywhere. Presumably it's commit f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM populate/dma map helper functions") instead, which makes the radeon driver rely on ttm_populate_and_map_pages, which is just a stub returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled. I can see two possible solutions: 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without SWIOTLB / INTEL_IOMMU as well. 2. Make the drivers work without ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages again in that case. Solution 1 would be preferable. Hello Michel, I tested the latest git version today. Unfortunately the problem with the hardware 3D acceleration still exist. How can I make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without SWIOTLB / INTEL_IOMMU? Thanks, Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100387] War Thunder game has visual errors, missing textures
https://bugs.freedesktop.org/show_bug.cgi?id=100387 --- Comment #18 from russianneuroman...@ya.ru --- Issue is still reproducible in Mesa 17.2. With Mesa 17.3 I get GPU lockup at War Thunder launch: bug 103900 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103900] [SUMO][TURKS] Launching War Thunder make GPU stuck, and then system is hard lockup
https://bugs.freedesktop.org/show_bug.cgi?id=103900 --- Comment #1 from russianneuroman...@ya.ru --- Created attachment 135708 --> https://bugs.freedesktop.org/attachment.cgi?id=135708=edit GPU lockup dmesg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103900] [SUMO][TURKS] Launching War Thunder make GPU stuck, and then system is hard lockup
https://bugs.freedesktop.org/show_bug.cgi?id=103900 Bug ID: 103900 Summary: [SUMO][TURKS] Launching War Thunder make GPU stuck, and then system is hard lockup Product: Mesa Version: 17.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: russianneuroman...@ya.ru QA Contact: dri-devel@lists.freedesktop.org Hello! Launching War Thunder make GPU stuck, and then system is hard lockup. This issue is starting to happen after upgrade from Mesa 17.2.2 with libdrm 2.4.83 to 17.3.0rc4 with libdrm 2.4.85 (from Padoka Stable PPA https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/pkppa ) on Kubuntu 17.10 x86_64. As soon as I rollback to Mesa 17.2.2 and libdrm 2.4.83, GPU lockup is no longer reproducible, but then there is another issue: bug 100387 Issue is reproducible on both of iGPU and dGPU. Please look into attached log. Hardware: Acer Aspire 7560G, AMD A8-3500M AMD Radeon HD 6620G iGPU, AMD Radeon HD 6650M dGPU. Software: Kubuntu 17.10 x86_64, Linux 4.14.1. radeon DDX and modesetting DDX was tested, no difference. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel