dri-devel July 2020

dri-devel@lists.freedesktop.org

336 participants
772 discussions

PROBLEM: kernel oops caused by vmwgfx_cmdbuf.c:399
by Carle, Peter 07 Jul '20

07 Jul '20

Good morning! Line 399 of vmwgfx_cmdbuf.c apparently causes a kernel oops that freezes the OS during boot-time. Here is the full line of the summary as reported by the Fedora notification system: --- WARNING: CPU: 2 PID: 414 at drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:399 vmw_cmdbuf_ctx_process+0x262/0x270 [vmwgfx] --- This problem started with Fedora 32's recent upgrade to kernel version 5.7 on July 2nd. It does not exist in kernel version 5.6. The problem occurs with Fedora running within VMware Workstation Pro on a Windows 10 host. It does not occur with VirtualBox. When I attempt to boot the VM, it freezes with a black screen after getting past the initial boot screen. I have included screenshots of the full error report from the notification system, since it was having trouble exporting it to text format. Probably the most pertinent screenshots are vmwgfx_crash.PNG and coredump_dmesg.PNG. Thank you!

2 1

[GIT PULL] mediatek drm fixes for 5.8
by Chun-Kuang Hu 07 Jul '20

07 Jul '20

Hi, Dave & David: This include fixup for cmdq, mmsys, visibility checking and some refinement. Regards, Chun-Kuang. The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-fixes-5.8 for you to fetch changes up to 5ab546f5e6309373aef01a8d398e163ab7a78431: drm/mediatek: mtk_hdmi: Remove debug messages for function calls (2020-07-05 06:39:21 +0800) ---------------------------------------------------------------- Mediatek DRM Fixes for Linux 5.8 ---------------------------------------------------------------- Bernard Zhao (1): drm/mediatek: Remove unnecessary conversion to bool Enric Balletbo i Serra (3): drm/mediatek: Remove debug messages for function calls drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables drm/mediatek: mtk_hdmi: Remove debug messages for function calls Hsin-Yi Wang (2): drm/mediatek: Fix device passed to cmdq drm/mediatek: Check plane visibility in atomic_update Matthias Brugger (1): drm/mediatek: Delete not used of_device_get_match_data YueHaibing (1): drm/mediatek: Fix Kconfig warning drivers/gpu/drm/mediatek/Kconfig | 2 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +--- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +-- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 25 ++++++++----- drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +-- drivers/gpu/drm/mediatek/mtk_hdmi.c | 12 +----- drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 52 -------------------------- 7 files changed, 22 insertions(+), 88 deletions(-)

1 1

[PATCH] drm/radeon: fix double free
by trix＠redhat.com 07 Jul '20

07 Jul '20

From: Tom Rix <trix(a)redhat.com> clang static analysis flags this error drivers/gpu/drm/radeon/ci_dpm.c:5652:9: warning: Use of memory after it is freed [unix.Malloc] kfree(rdev->pm.dpm.ps[i].ps_priv); ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/radeon/ci_dpm.c:5654:2: warning: Attempt to free released memory [unix.Malloc] kfree(rdev->pm.dpm.ps); ^~~~~~~~~~~~~~~~~~~~~~ problem is reported in ci_dpm_fini, with these code blocks. for (i = 0; i < rdev->pm.dpm.num_ps; i++) { kfree(rdev->pm.dpm.ps[i].ps_priv); } kfree(rdev->pm.dpm.ps); The first free happens in ci_parse_power_table where it cleans up locally on a failure. ci_dpm_fini also does a cleanup. ret = ci_parse_power_table(rdev); if (ret) { ci_dpm_fini(rdev); return ret; } So remove the cleanup in ci_parse_power_table and move the num_ps calculation to inside the loop so ci_dpm_fini will know how many array elements to free. Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)") Signed-off-by: Tom Rix <trix(a)redhat.com> --- drivers/gpu/drm/radeon/ci_dpm.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index 86ac032275bb..ba20c6f03719 100644 --- a/drivers/gpu/drm/radeon/ci_dpm.c +++ b/drivers/gpu/drm/radeon/ci_dpm.c @@ -5563,6 +5563,7 @@ static int ci_parse_power_table(struct radeon_device *rdev) if (!rdev->pm.dpm.ps) return -ENOMEM; power_state_offset = (u8 *)state_array->states; + rdev->pm.dpm.num_ps = 0; for (i = 0; i < state_array->ucNumEntries; i++) { u8 *idx; power_state = (union pplib_power_state *)power_state_offset; @@ -5572,10 +5573,8 @@ static int ci_parse_power_table(struct radeon_device *rdev) if (!rdev->pm.power_state[i].clock_info) return -EINVAL; ps = kzalloc(sizeof(struct ci_ps), GFP_KERNEL); - if (ps == NULL) { - kfree(rdev->pm.dpm.ps); + if (ps == NULL) return -ENOMEM; - } rdev->pm.dpm.ps[i].ps_priv = ps; ci_parse_pplib_non_clock_info(rdev, &rdev->pm.dpm.ps[i], non_clock_info, @@ -5597,8 +5596,8 @@ static int ci_parse_power_table(struct radeon_device *rdev) k++; } power_state_offset += 2 + power_state->v2.ucNumDPMLevels; + rdev->pm.dpm.num_ps = i + 1; } - rdev->pm.dpm.num_ps = state_array->ucNumEntries; /* fill in the vce power states */ for (i = 0; i < RADEON_MAX_VCE_LEVELS; i++) { -- 2.18.1

2 1

[PATCH] drm/meson: overlay: fix build failure
by Neil Armstrong 07 Jul '20

07 Jul '20

The recent GCC compiler is very picky with the VD_H_START() and AFBC_DEC_PIXEL_BGN_H() macros, triggering a runtime assert error as: In function 'meson_overlay_setup_scaler_params', inlined from 'meson_overlay_atomic_update' at drivers/gpu/drm/meson/meson_overlay.c:542:2: ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_341' declared with attribute error: FIELD_PREP: value too large for the field drivers/gpu/drm/meson/meson_overlay.c:413:4: note: in expansion of macro 'AFBC_DEC_PIXEL_BGN_H' 413 | AFBC_DEC_PIXEL_BGN_H(hd_start_lines - afbc_left) | | ^~~~~~~~~~~~~~~~~~~~ ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_401' declared with attribute error: FIELD_PREP: value too large for the field It's not expected to overflow these fields, but the compiler did find a case where it overflows. We can safely ignore this, so mask the value with the field width. Fixes: e860785d57306 ("drm/meson: overlay: setup overlay for Amlogic FBC") Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- Got Daniel's Ack from irc drivers/gpu/drm/meson/meson_overlay.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_overlay.c b/drivers/gpu/drm/meson/meson_overlay.c index 1f7b2055e012..646e605f30f3 100644 --- a/drivers/gpu/drm/meson/meson_overlay.c +++ b/drivers/gpu/drm/meson/meson_overlay.c @@ -58,7 +58,8 @@ /* VPP_POSTBLEND_VD1_H_START_END */ #define VD_H_END(value) FIELD_PREP(GENMASK(11, 0), value) -#define VD_H_START(value) FIELD_PREP(GENMASK(27, 16), value) +#define VD_H_START(value) FIELD_PREP(GENMASK(27, 16), \ + (value & GENMASK(13, 0))) /* VPP_POSTBLEND_VD1_V_START_END */ #define VD_V_END(value) FIELD_PREP(GENMASK(11, 0), value) @@ -144,7 +145,8 @@ #define AFBC_MIF_BLK_END_V(value) FIELD_PREP(GENMASK(11, 0), value) /* AFBC_PIXEL_HOR_SCOPE */ -#define AFBC_DEC_PIXEL_BGN_H(value) FIELD_PREP(GENMASK(28, 16), value) +#define AFBC_DEC_PIXEL_BGN_H(value) FIELD_PREP(GENMASK(28, 16), \ + (value & GENMASK(12, 0))) #define AFBC_DEC_PIXEL_END_H(value) FIELD_PREP(GENMASK(12, 0), value) /* AFBC_PIXEL_VER_SCOPE */ -- 2.22.0

1 1

[RFC] drm/vgem: Don't use get_page in fault handler.
by Lepton Wu 07 Jul '20

07 Jul '20

For pages which are allocated in ttm with transparent huge pages, tail pages have zero as reference count. The current vgem code use get_page on them and it will trigger BUG when release_pages get called on those pages later. Here I attach the minimal code to trigger this bug on a qemu VM which enables virtio gpu (card1) and vgem (card0). BTW, since the upstream virtio gpu has changed to use drm gem and moved away from ttm. So we have to use an old kernel like 5.4 to reproduce it. But I guess same thing could happen for a real GPU if the real GPU use similar code path to allocate pages from ttm. I am not sure about two things: first, do we need to fix this? will a real GPU hit this code path? Second, suppose this need to be fixed, should this be fixed in ttm side or vgem side? If we remove "huge_flags &= ~__GFP_COMP" from ttm_get_pages, then get_page in vgem works fine. But it's there for fix another bug: https://bugs.freedesktop.org/show_bug.cgi?id=103138 It could also be "fixed" with this patch. But I am really not sure if this is the way to go. Here is the code to reproduce this bug: unsigned int WIDTH = 1024; unsigned int HEIGHT = 513; unsigned int size = WIDTH * HEIGHT * 4; int work(int vfd, int dfd, int handle) { int ret; struct drm_prime_handle hf = {.handle = handle }; ret = ioctl(dfd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &hf); fprintf(stderr, "fd is %d\n", hf.fd); hf.flags = DRM_CLOEXEC | DRM_RDWR; ret = ioctl(vfd, DRM_IOCTL_PRIME_FD_TO_HANDLE, &hf); fprintf(stderr, "new handle is %d\n", hf.handle); struct drm_mode_map_dumb map = {.handle = hf.handle }; ret = ioctl(vfd, DRM_IOCTL_MODE_MAP_DUMB, &map); fprintf(stderr, "need map at offset %lld\n", map.offset); unsigned char * ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, vfd, map.offset); memset(ptr, 2, size); munmap(ptr, size); } int main() { int vfd = open("/dev/dri/card0", O_RDWR); // vgem int dfd = open("/dev/dri/card1", O_RDWR); // virtio gpu int ret; struct drm_mode_create_dumb ct = {}; ct.height = HEIGHT; ct.width = WIDTH; ct.bpp = 32; ret = ioctl(dfd, DRM_IOCTL_MODE_CREATE_DUMB, &ct); work(vfd, dfd, ct.handle); fprintf(stderr, "done\n"); } Signed-off-by: Lepton Wu <ytht.net(a)gmail.com> --- drivers/gpu/drm/vgem/vgem_drv.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index ec1a8ebb6f1b..be3d97e29804 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -87,9 +87,8 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf) mutex_lock(&obj->pages_lock); if (obj->pages) { - get_page(obj->pages[page_offset]); - vmf->page = obj->pages[page_offset]; - ret = 0; + ret = vmf_insert_pfn(vmf->vma, vmf->address, + page_to_pfn(obj->pages[page_offset])); } mutex_unlock(&obj->pages_lock); if (ret) { @@ -263,7 +262,6 @@ static struct drm_ioctl_desc vgem_ioctls[] = { static int vgem_mmap(struct file *filp, struct vm_area_struct *vma) { - unsigned long flags = vma->vm_flags; int ret; ret = drm_gem_mmap(filp, vma); @@ -273,7 +271,6 @@ static int vgem_mmap(struct file *filp, struct vm_area_struct *vma) /* Keep the WC mmaping set by drm_gem_mmap() but our pages * are ordinary and not special. */ - vma->vm_flags = flags | VM_DONTEXPAND | VM_DONTDUMP; return 0; } -- 2.27.0.212.ge8ba1cc988-goog

5 7

[PATCH 1/2] drm/panel-simple: Fix inverted V/H SYNC for Frida FRD350H54004 panel
by Paul Cercueil 07 Jul '20

07 Jul '20

The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC signals, which sorts-of worked, but resulted in the picture fading out under certain circumstances. Fix this issue by marking VSYNC and HSYNC signals active-low. Fixes: 7b6bd8433609 ("drm/panel: simple: Add support for the Frida FRD350H54004 panel") Cc: stable(a)vger.kernel.org # v5.5 Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 5178f87d6574..1188d191076b 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -1703,7 +1703,7 @@ static const struct drm_display_mode frida_frd350h54004_mode = { .vsync_end = 240 + 2 + 6, .vtotal = 240 + 2 + 6 + 2, .vrefresh = 60, - .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC, + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, }; static const struct panel_desc frida_frd350h54004 = { -- 2.27.0

1 1

[PATCH] drm/of: Consider the state in which the ep is disabled
by Sandy Huang 07 Jul '20

07 Jul '20

don't mask possible_crtcs if remote-point is disabled. Signed-off-by: Sandy Huang <hjc(a)rock-chips.com> --- drivers/gpu/drm/drm_of.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c index fdb05fbf72a0..f5f250435add 100644 --- a/drivers/gpu/drm/drm_of.c +++ b/drivers/gpu/drm/drm_of.c @@ -66,6 +66,11 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev, uint32_t possible_crtcs = 0; for_each_endpoint_of_node(port, ep) { + if (!of_device_is_available(ep)) { + of_node_put(ep); + continue; + } + remote_port = of_graph_get_remote_port(ep); if (!remote_port) { of_node_put(ep); -- 2.17.1

3 2

[PATCH v2] drm/exynos: Fix dma_parms allocation
by Marek Szyprowski 07 Jul '20

07 Jul '20

Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") driver core handles allocation of the dma_parms structure for platform device, so there is no need to manually allocate nor free it. Reported-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- v2: - rebased onto current exynos-drm-next --- drivers/gpu/drm/exynos/exynos_drm_dma.c | 27 +------------------------ 1 file changed, 1 insertion(+), 26 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c index 58b89ec11b0e..5887f7f52f96 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dma.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c @@ -31,23 +31,6 @@ #define EXYNOS_DEV_ADDR_START 0x20000000 #define EXYNOS_DEV_ADDR_SIZE 0x40000000 -static inline int configure_dma_max_seg_size(struct device *dev) -{ - if (!dev->dma_parms) - dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL); - if (!dev->dma_parms) - return -ENOMEM; - - dma_set_max_seg_size(dev, DMA_BIT_MASK(32)); - return 0; -} - -static inline void clear_dma_max_seg_size(struct device *dev) -{ - kfree(dev->dma_parms); - dev->dma_parms = NULL; -} - /* * drm_iommu_attach_device- attach device to iommu mapping * @@ -69,10 +52,7 @@ static int drm_iommu_attach_device(struct drm_device *drm_dev, return -EINVAL; } - ret = configure_dma_max_seg_size(subdrv_dev); - if (ret) - return ret; - + dma_set_max_seg_size(subdrv_dev, DMA_BIT_MASK(32)); if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)) { /* * Keep the original DMA mapping of the sub-device and @@ -89,9 +69,6 @@ static int drm_iommu_attach_device(struct drm_device *drm_dev, ret = iommu_attach_device(priv->mapping, subdrv_dev); } - if (ret) - clear_dma_max_seg_size(subdrv_dev); - return ret; } @@ -114,8 +91,6 @@ static void drm_iommu_detach_device(struct drm_device *drm_dev, arm_iommu_attach_device(subdrv_dev, *dma_priv); } else if (IS_ENABLED(CONFIG_IOMMU_DMA)) iommu_detach_device(priv->mapping, subdrv_dev); - - clear_dma_max_seg_size(subdrv_dev); } int exynos_drm_register_dma(struct drm_device *drm, struct device *dev, -- 2.17.1

1 0

[PATCH v4 0/9] drm/vc4: Turn the TXP into a CRTC
by Maxime Ripard 07 Jul '20

07 Jul '20

Hi, This is another part of the rpi4 HDMI series that got promoted to a series of its own to try to reduce the main one. This rework is needed since the bcm2711 used in the rpi4 has a more complex routing in the HVS that doesn't allow to use a fairly simple mapping like what was used before. Since that mapping affects both the pixelvalves and the TXP, turning the TXP into a CRTC just like pixelvalves are allows to deal with the mapping in the CRTC states, which turns out to be pretty convenient. Let me know what you think, Maxime Changes from v3: - Stripped the patches out of the main HDMI series - Change the bind order of the HVS to avoid a compatible check - Added Eric's tags - Rebased on top of drm-misc-next Maxime Ripard (9): drm/vc4: Reorder the bind order of the devices drm/vc4: crtc: Move HVS setup code to the HVS driver drm/vc4: crtc: Make state functions public drm/vc4: crtc: Split CRTC data in two drm/vc4: crtc: Only access the PixelValve registers if we have to drm/vc4: crtc: Move the CRTC initialisation to a separate function drm/vc4: crtc: Move the txp_armed function to the TXP drm/vc4: txp: Turn the TXP into a CRTC of its own drm/vc4: crtc: Remove the feed_txp tests drivers/gpu/drm/vc4/vc4_crtc.c | 427 ++++++---------------------------- drivers/gpu/drm/vc4/vc4_drv.c | 2 +- drivers/gpu/drm/vc4/vc4_drv.h | 38 ++- drivers/gpu/drm/vc4/vc4_hvs.c | 291 +++++++++++++++++++++++- drivers/gpu/drm/vc4/vc4_txp.c | 109 ++++++++- 5 files changed, 522 insertions(+), 345 deletions(-) base-commit: ebd11f706c9d9756edad5b5f3f3310d77d77f60c -- git-series 0.9.1

2 12

[PATCH] drm/vc4: Convert register accessors to FIELD_*
by Maxime Ripard 07 Jul '20

07 Jul '20

The VC4_SET_FIELD and VC4_GET_FIELD are reimplementing most of the logic already defined in FIELD_SET and FIELD_GET. Let's convert the vc4 macros to use the FIELD_* macros. Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- drivers/gpu/drm/vc4/vc4_regs.h | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h index b5a6b4cdd332..324462cc9cd4 100644 --- a/drivers/gpu/drm/vc4/vc4_regs.h +++ b/drivers/gpu/drm/vc4/vc4_regs.h @@ -6,19 +6,18 @@ #ifndef VC4_REGS_H #define VC4_REGS_H +#include <linux/bitfield.h> #include <linux/bitops.h> #define VC4_MASK(high, low) ((u32)GENMASK(high, low)) /* Using the GNU statement expression extension */ #define VC4_SET_FIELD(value, field) \ ({ \ - uint32_t fieldval = (value) << field##_SHIFT; \ - WARN_ON((fieldval & ~field##_MASK) != 0); \ - fieldval & field##_MASK; \ + WARN_ON(!FIELD_FIT(field##_MASK, value)); \ + FIELD_PREP(field##_MASK, value); \ }) -#define VC4_GET_FIELD(word, field) (((word) & field##_MASK) >> \ - field##_SHIFT) +#define VC4_GET_FIELD(word, field) FIELD_GET(field##_MASK, word) #define V3D_IDENT0 0x00000 # define V3D_EXPECTED_IDENT0 \ -- 2.26.2

2 2

← Newer
1
...
64
65
66
67
68
69
70
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2020