dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

KASAN: global-out-of-bounds Read in fbcon_get_font
by syzbot 30 Sep '20

30 Sep '20

Hello, syzbot found the following crash on: HEAD commit: 6cf8298d Add linux-next specific files for 20191209 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=168bbb7ae00000 kernel config: https://syzkaller.appspot.com/x/.config?x=682fc0ce6c86e3c7 dashboard link: https://syzkaller.appspot.com/bug?extid=29d4ed7f3bdedf2aa2fd compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12fff061e00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+29d4ed7f3bdedf2aa2fd(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: global-out-of-bounds in memcpy include/linux/string.h:425 [inline] BUG: KASAN: global-out-of-bounds in fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465 Read of size 32 at addr ffffffff88729d80 by task syz-executor.3/9100 CPU: 1 PID: 9100 Comm: syz-executor.3 Not tainted 5.5.0-rc1-next-20191209-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 memcpy+0x24/0x50 mm/kasan/common.c:125 memcpy include/linux/string.h:425 [inline] fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465 con_font_get drivers/tty/vt/vt.c:4446 [inline] con_font_op+0x20b/0x1270 drivers/tty/vt/vt.c:4605 vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913 tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45a6f9 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f30314dcc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045a6f9 RDX: 0000000000713000 RSI: 0000000000004b60 RDI: 0000000000000004 RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f30314dd6d4 R13: 00000000004c6d87 R14: 00000000004dd3e0 R15: 00000000ffffffff The buggy address belongs to the variable: fontdata_8x16+0x1000/0x1120 Memory state around the buggy address: ffffffff88729c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff88729d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffffff88729d80: fa fa fa fa 06 fa fa fa fa fa fa fa 05 fa fa fa ^ ffffffff88729e00: fa fa fa fa 06 fa fa fa fa fa fa fa 00 00 03 fa ffffffff88729e80: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

7 28

[PATCH v5 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse
by Marek Szyprowski 30 Sep '20

30 Sep '20

Dear All, During the Exynos DRM GEM rework and fixing the issues in the. drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most drivers in DRM framework incorrectly use nents and orig_nents entries of the struct sg_table. In case of the most DMA-mapping implementations exchanging those two entries or using nents for all loops on the scatterlist is harmless, because they both have the same value. There exists however a DMA-mapping implementations, for which such incorrect usage breaks things. The nents returned by dma_map_sg() might be lower than the nents passed as its parameter and this is perfectly fine. DMA framework or IOMMU is allowed to join consecutive chunks while mapping if such operation is supported by the underlying HW (bus, bridge, IOMMU, etc). Example of the case where dma_map_sg() might return 1 'DMA' chunk for the 4 'physical' pages is described here [2] The DMA-mapping framework documentation [3] states that dma_map_sg() returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of entries passed to dma_map_sg. The common pattern in DRM drivers were to assign the dma_map_sg() return value to sg_table->nents and use that value for the subsequent calls to dma_sync_sg_* or dma_unmap_sg functions. Also the code iterated over nents times to access the pages stored in the processed scatterlist, while it should use orig_nents as the numer of the page entries. I've tried to identify all such incorrect usage of sg_table->nents and this is a result of my research. It looks that the incorrect pattern has been copied over the many drivers mainly in the DRM subsystem. Too bad in most cases it even worked correctly if the system used a simple, linear DMA-mapping implementation, for which swapping nents and orig_nents doesn't make any difference. To avoid similar issues in the future, I've introduced a common wrappers for DMA-mapping calls, which operate directly on the sg_table objects. I've also added wrappers for iterating over the scatterlists stored in the sg_table objects and applied them where possible. This, together with some common DRM prime helpers, allowed me to almost get rid of all nents/orig_nents usage in the drivers. I hope that such change makes the code robust, easier to follow and copy/paste safe. The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix it fully. The driver creatively uses sg_table->orig_nents to store the size of the allocate scatterlist and ignores the number of the entries returned by dma_map_sg function. In this patchset I only fixed the sg_table objects exported by dmabuf related functions. I hope that I didn't break anything there. Patches are based on top of Linux next-20200512. Christoph Hellwig already offered to take patches 1-3 into his immutable branch [4]. If possible I would like ask for merging most of the remaining patches via DRM tree (on top of that immutable branch). Best regards, Marek Szyprowski References: [1] https://lkml.org/lkml/2020/3/27/555 [2] https://lkml.org/lkml/2020/3/29/65 [3] Documentation/DMA-API-HOWTO.txt [4] https://lore.kernel.org/linux-iommu/20200512121931.GD20393@lst.de/T/#ma18c9… Changelog: v5: - fixed some minor style issues and typos - fixed lack of the attrs argument in ion, dmabuf, rapidio, fastrpc and vfio patches v4: https://lore.kernel.org/linux-iommu/20200512121931.GD20393@lst.de/T/ - added for_each_sgtable_* wrappers and applied where possible - added drm_prime_get_contiguous_size() and applied where possible - applied drm_prime_sg_to_page_addr_arrays() where possible to remove page extraction from sg_table objects - added documentation for the introduced wrappers - improved patches description a bit v3: https://lore.kernel.org/dri-devel/20200505083926.28503-1-m.szyprowski@samsu… - introduce dma_*_sgtable_* wrappers and use them in all patches v2: https://lore.kernel.org/linux-iommu/c01c9766-9778-fd1f-f36e-2dc7bd376ba4@ar… - dropped most of the changes to drm/i915 - added fixes for rcar-du, xen, media and ion - fixed a few issues pointed by kbuild test robot - added wide cc: list for each patch v1: https://lore.kernel.org/linux-iommu/c01c9766-9778-fd1f-f36e-2dc7bd376ba4@ar… - initial version Patch summary: Marek Szyprowski (38): dma-mapping: add generic helpers for mapping sgtable objects scatterlist: add generic wrappers for iterating over sgtable objects iommu: add generic helper for mapping sgtable objects drm: prime: add common helper to check scatterlist contiguity drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays() drm: core: fix common struct sg_table related issues drm: amdgpu: fix common struct sg_table related issues drm: armada: fix common struct sg_table related issues drm: etnaviv: fix common struct sg_table related issues drm: exynos: use common helper for a scatterlist contiguity check drm: exynos: fix common struct sg_table related issues drm: i915: fix common struct sg_table related issues drm: lima: fix common struct sg_table related issues drm: mediatek: use common helper for a scatterlist contiguity check drm: mediatek: use common helper for extracting pages array drm: msm: fix common struct sg_table related issues drm: omapdrm: use common helper for extracting pages array drm: omapdrm: fix common struct sg_table related issues drm: panfrost: fix common struct sg_table related issues drm: radeon: fix common struct sg_table related issues drm: rockchip: use common helper for a scatterlist contiguity check drm: rockchip: fix common struct sg_table related issues drm: tegra: fix common struct sg_table related issues drm: v3d: fix common struct sg_table related issues drm: virtio: fix common struct sg_table related issues drm: vmwgfx: fix common struct sg_table related issues xen: gntdev: fix common struct sg_table related issues drm: host1x: fix common struct sg_table related issues drm: rcar-du: fix common struct sg_table related issues dmabuf: fix common struct sg_table related issues staging: ion: remove dead code staging: ion: fix common struct sg_table related issues staging: tegra-vde: fix common struct sg_table related issues misc: fastrpc: fix common struct sg_table related issues rapidio: fix common struct sg_table related issues samples: vfio-mdev/mbochs: fix common struct sg_table related issues media: pci: fix common ALSA DMA-mapping related codes videobuf2: use sgtable-based scatterlist wrappers drivers/dma-buf/heaps/heap-helpers.c | 13 ++-- drivers/dma-buf/udmabuf.c | 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 9 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 +- drivers/gpu/drm/armada/armada_gem.c | 12 +-- drivers/gpu/drm/drm_cache.c | 2 +- drivers/gpu/drm/drm_gem_cma_helper.c | 23 +----- drivers/gpu/drm/drm_gem_shmem_helper.c | 14 ++-- drivers/gpu/drm/drm_prime.c | 86 ++++++++++++---------- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 12 ++- drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 13 +--- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +-- drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +----- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +-- drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +- drivers/gpu/drm/lima/lima_gem.c | 11 ++- drivers/gpu/drm/lima/lima_vm.c | 5 +- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 34 ++------- drivers/gpu/drm/msm/msm_gem.c | 13 ++-- drivers/gpu/drm/msm/msm_gpummu.c | 14 ++-- drivers/gpu/drm/msm/msm_iommu.c | 2 +- drivers/gpu/drm/omapdrm/omap_gem.c | 20 ++--- drivers/gpu/drm/panfrost/panfrost_gem.c | 4 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +- drivers/gpu/drm/radeon/radeon_ttm.c | 11 ++- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 42 +++-------- drivers/gpu/drm/tegra/gem.c | 27 +++---- drivers/gpu/drm/tegra/plane.c | 15 ++-- drivers/gpu/drm/v3d/v3d_mmu.c | 17 ++--- drivers/gpu/drm/virtio/virtgpu_object.c | 36 +++++---- drivers/gpu/drm/virtio/virtgpu_vq.c | 12 ++- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 17 +---- drivers/gpu/host1x/job.c | 22 ++---- .../media/common/videobuf2/videobuf2-dma-contig.c | 41 +++++------ drivers/media/common/videobuf2/videobuf2-dma-sg.c | 32 +++----- drivers/media/common/videobuf2/videobuf2-vmalloc.c | 12 +-- drivers/media/pci/cx23885/cx23885-alsa.c | 2 +- drivers/media/pci/cx25821/cx25821-alsa.c | 2 +- drivers/media/pci/cx88/cx88-alsa.c | 2 +- drivers/media/pci/saa7134/saa7134-alsa.c | 2 +- drivers/media/platform/vsp1/vsp1_drm.c | 8 +- drivers/misc/fastrpc.c | 4 +- drivers/rapidio/devices/rio_mport_cdev.c | 8 +- drivers/staging/android/ion/ion.c | 25 +++---- drivers/staging/android/ion/ion.h | 1 - drivers/staging/android/ion/ion_heap.c | 53 ++++--------- drivers/staging/android/ion/ion_system_heap.c | 2 +- drivers/staging/media/tegra-vde/iommu.c | 4 +- drivers/xen/gntdev-dmabuf.c | 13 ++-- include/drm/drm_prime.h | 2 + include/linux/dma-mapping.h | 78 ++++++++++++++++++++ include/linux/iommu.h | 16 ++++ include/linux/scatterlist.h | 50 ++++++++++++- samples/vfio-mdev/mbochs.c | 3 +- 56 files changed, 451 insertions(+), 477 deletions(-) -- 1.9.1

10 52

[Bug 198551] New: amdgpu error on shutdown or gpu intense game
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '20

24 Sep '20

https://bugzilla.kernel.org/show_bug.cgi?id=198551 Bug ID: 198551 Summary: amdgpu error on shutdown or gpu intense game Product: Drivers Version: 2.5 Kernel Version: 4.14.14-1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: illuslion1998(a)gmail.com Regression: No Created attachment 273797 --> https://bugzilla.kernel.org/attachment.cgi?id=273797&action=edit amdgpu error log I get this error sometimes when I try to shutdown my computer. It freezes everything and I have to hard reset my computer. This sometimes also happens when I play a GPU intense game. (Example CS:GO). My GPU is Radeon R5 M255. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
by Daniel Vetter 23 Sep '20

23 Sep '20

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index d5cefb1cb2a2..058512f14772 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -2018,15 +2018,43 @@ EXPORT_SYMBOL(drm_atomic_commit); int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; - int ret; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + bool nonblocking = true; + int ret, i; + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * + * But when userspace also requests a nonblocking commit then userspace + * cannot know that the commit affects other CRTCs, which can result in + * spurious EBUSY failures. Until we have better uapi plug this by + * demoting such commits to blocking mode. + */ + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); ret = drm_atomic_check_only(state); if (ret) return ret; - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + if (affected_crtc != requested_crtc) { + /* adding other CRTC is only allowed for modeset commits */ + WARN_ON(state->allow_modeset); + + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state); + nonblocking = false; + } else { + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + } - return config->funcs->atomic_commit(state->dev, state, true); + return config->funcs->atomic_commit(state->dev, state, nonblocking); } EXPORT_SYMBOL(drm_atomic_nonblocking_commit); -- 2.18.0

3 11

[PATCH 1/4] drm: pl111: Credit where credit is due
by Linus Walleij 22 Sep '20

22 Sep '20

This moves over some of the credit for the development of this driver from the old fbdev driver that I used as reference when getting this in place. Cc: Russell King <linux(a)armlinux.org.uk> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/gpu/drm/pl111/pl111_versatile.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c index 64f01a4e6767..1127082e9a60 100644 --- a/drivers/gpu/drm/pl111/pl111_versatile.c +++ b/drivers/gpu/drm/pl111/pl111_versatile.c @@ -1,5 +1,14 @@ // SPDX-License-Identifier: GPL-2.0-only +/* + * Versatile family (ARM reference designs) handling for the PL11x. + * This is based on code and know-how in the previous frame buffer + * driver in drivers/video/fbdev/amba-clcd.c: + * Copyright (C) 2001 ARM Limited, by David A Rusling + * Updated to 2.5 by Deep Blue Solutions Ltd. + * Major contributions and discoveries by Russell King. + */ + #include <linux/amba/clcd-regs.h> #include <linux/bitops.h> #include <linux/device.h> -- 2.25.4

8 17

[PATCH 0/7] drm/omap: misc improvements
by Tomi Valkeinen 22 Sep '20

22 Sep '20

Hi, Misc improvements to omapdrm which have been lying around for a long time, and I've missed upstreaming them. And one new one, which makes the DSS5 HDMI pick up the color range automatically. Tomi Alejandro Hernandez (1): drm/omap: tweak HDMI DDC timings Jyri Sarha (3): drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes drm/omap: dss: platform_register_drivers() to dss.c and remove core.c Tomi Valkeinen (3): drm/omap: drop unneeded locking from mgr_fld_write() drm/omap: fix missing scaler pixel fmt limitations drm/omap: hdmi5: automatically choose limited/full range output drivers/gpu/drm/omapdrm/dss/Makefile | 2 +- drivers/gpu/drm/omapdrm/dss/core.c | 55 -------- drivers/gpu/drm/omapdrm/dss/dispc.c | 160 +++++++++++++++++------ drivers/gpu/drm/omapdrm/dss/dss.c | 37 ++++++ drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 125 ++++++++++-------- drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 + drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++++- drivers/gpu/drm/omapdrm/omap_plane.c | 30 +++++ 8 files changed, 295 insertions(+), 157 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 33

[RESEND] [PATCH v6 0/8] do not store GPU address in TTM
by Nirmoy Das 21 Sep '20

21 Sep '20

With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. This cleanup will simplify introduction of drm_mem_region/domain work started by Brian Welty[1]. It would be nice if someone test this for nouveau. Rest of the drivers are already tested. v2: * set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL v3: * catch return value of drm_gem_vram_offset() in drm/bochs * introduce drm_gem_vram_pg_offset() in vram helper * improve nbo->offset calculation for nouveau v4: * minor coding style fixes in amdgpu and radeon * remove unnecessary kerneldoc for internal function v5: * rebase on top of drm-misc-next * fix return value of drm_gem_vram_pg_offset() * add a comment in drm_gem_vram_pg_offset() to clearify why we return 0. v6: * rebase to drm-misc-next * removed acked for vmwgfx as there was a small conflict Nirmoy Das (8): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset v3 drm/qxl: don't use ttm bo->offset drm/vram-helper: don't use ttm bo->offset v4 drm/bochs: use drm_gem_vram_offset to get bo offset v2 drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++++++++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 ++++++++++++++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +-- drivers/gpu/drm/bochs/bochs_kms.c | 7 ++++- drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++++++- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 ++++++ drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++---- drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h | 5 ---- drivers/gpu/drm/qxl/qxl_ttm.c | 9 ------- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 ++++++++++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c | 7 ----- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h | 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 36 files changed, 125 insertions(+), 78 deletions(-) -- 2.27.0

5 24

Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
by Christian König 16 Sep '20

16 Sep '20

Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: > Hi Woody, > > sorry for the late reply, I've been off to a vacation over the holidays. > > On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: >> Regression in 5.4 kernel on 32-bit Radeon IBM T40 >> triggered by >> commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 >> Author: Christoph Hellwig <hch(a)lst.de> >> Date: Thu Aug 15 09:27:00 2019 +0200 >> >> Howdy, >> The above patch has triggered a display problem on IBM Thinkpad T40, where >> the screen is covered with a lots of random short black horizontal lines, >> or distorted letters in X terms. >> >> The culprit seems to be that the dma_get_required_mask() is returning a >> value 0x3fffffff >> which is smaller than dma_get_mask()0xffffffff.That results in >> dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma >> instead of 32-bits. > Which is the intended behavior assuming your system has 1GB of memory. > Does it? Assuming the system doesn't have the 1GB split up somehow crazy over the address space that should indeed work as intended. > >> If I hardcode "1" as the last parameter to ttm_bo_device_init() in place of >> a call to dma_addressing_limited(),the problem goes away. > I'll need some help from the drm / radeon / TTM maintainers if there are > any other side effects from not passing the need_dma32 paramters. > Obviously if the device doesn't have more than 32-bits worth of dram and > no DMA offset we can't feed unaddressable memory to the device. > Unfortunately I have a very hard time following the implementation of > the TTM pool if it does anything else in this case. The only other thing which comes to mind is using huge pages. Can you try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled? Thanks, Christian.

5 5

Re: backend-drm and scanning really large resolutions
by Pekka Paalanen 12 Sep '20

12 Sep '20

Adding Rob back in CC, I don't know if he is subscribed to wayland-devel@. You forgot to CC dri-devel@ too. On Tue, 11 Feb 2020 17:18:52 -0500 Xiaowen Wu <wxiaowen(a)codeaurora.org> wrote: > Hi Rob, > > If the vendor driver doesn't have the hwpipe sub-object and kms plane is > one-to-one mapped to hwpipe (sspp), > do you think if below approach is acceptable if we still want to > virtualize the kms plane to support 4K/8K scanout? > > 1. At kms atomic check before calling drm_atomic_helper_check, depending > on scanout width of plane A in state, add idle planes B (C,D,...) > into the same atomic state, backup and then modify > src_x/src_w/crtc_x/crtc_w of plane A and the affected planes B (C,D,...) > to meet scanout > width limits, and set crtc/fb of the affected planes B (C,D,...) same as > plane A. > > 2. At plane's state duplicate function, check if plane's > src_x/src_w/crtc_x/crtc_w are updated at step 1), if so revert the > change to > plane A's backup value to allow plane A's scanout to update again. These > value will again be updated in step 1) so nothing really changes > if plane A continues updating. > > 3. If plane A's scanout is updated or detached from crtc, detach > affected planes B (C,D,...) in the same atomic state in step 1) and then > run step 1) again. > > 4. If user want to commit plane B (C,D,...), the commit/test will fail > if planes are already used as sister plane of plane A. This failure is > same > as insufficient hwpipe from plane B (C,D,...). > > With above change, any downstream driver can support virtualized plane. > Also as the above approach is generic and not h/w specific, we can make > it a helper function and it's up to vendor to choose if they want to use > or not, if they don't have logic like drm/msm/disp/mdp5/mdp5_plane in > their downstream driver. > > Conceptional above changes didn't borrow hwpipe resources from other > plane but borrow planes themselves directly, however from user point of > view > they should not feel any difference. > > What do you think? > > BR, > Xiaowen Wu > > > On Tue Jan 21, 2020 at 4:12 PM Rob Clark <robdclark at gmail.com> wrote: > > On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier <matt.hoosier at > > gmail.com> wrote: > >> > >> Hi all, > >> > >> I'm confronting a situation where the hardware with which I work is > >> capable of driving connectors at 4K or 8K, but doing so requires > >> bonding the scanning of multiple planes together. > >> > >> The scenario is that you'd have a big primary framebuffer whose size > >> is too large for an individual hardware scanning pipeline on the > >> display controller to traverse within its maximum allowed clock rate. > >> > >> The hardware supplier's approach is to assign multiple planes, which > >> in the KMS driver map to hardware scanning pipelines, to each be > >> responsible for scanning a smaller section of the framebuffer. The > >> planes are all assigned to the same CRTC, and in concert with each > >> other they cover the whole area of the framebuffer and CRTC. > >> > >> This sounds a little bit wild to me. I hadn't been aware it's even > >> legal to have more than one plane treated a the source of scanout for > >> a single framebuffer. Maybe that distinction isn't really relevant > >> nowadays with universal plane support. > >> > > > > fwiw, have a look at drm/msm/disp/mdp5/mdp5_plane, which will allocate > > one or two hwpipe's from the devices global atomic state, depending on > > scanout width.. the hwpipe (sspp) is the physical resource behind a > > plane, so essentially the kms planes are virtualized. At some point > > if you have too many wide layers, the atomic test step will fail due > > to insufficient hwpipe's. But this sort of scenario is the reason for > > the test step. > > > > BR, > > -R > > > >> I'm wondering if anybody here knows whether this a legit approach for > >> a compositor's DRM backend to take? > >> > _______________________________________________ > wayland-devel mailing list > wayland-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel

3 2

Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780
by Paul Boddie 10 Sep '20

10 Sep '20

Hello, On and off over the past few months, I have been looking at getting the Synopsys DesignWare HDMI peripheral used in the Ingenic JZ4780 SoC working with a recent kernel. Unfortunately, what probably should be a straightforward task is proving more difficult than it seems, and I have been advised to ask for advice on this list. == Background == Previously, in the vendor kernels released by Imagination Technologies for the MIPS Creator CI20, there were specialised HDMI drivers for the JZ4780: * One (based on Linux 3.0.8) which seems to use a Synopsys hardware abstraction layer. * Another (based on Linux 3.18) where the driver incorporates code used to support Freescale products and cooperates with a "CRTC" driver that has since been replaced by the ingenic-drm.c driver. Since the Freescale-related code now seems to reside as a kind of generic driver in drivers/gpu/drm/bridge/synopsys [1], with some other drivers specialising this generic support, I thought that it might be straightforward to specialise the code similarly for the JZ4780. Unfortunately, I have not managed to achieve this so far, and I imagine that I must have overlooked something. == Summary of Work == What I have done so far is to add a new file to... drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c (See [2] for the full file.) This specialises the generic dw-hdmi.c driver and is heavily based on the existing driver in... drivers/gpu/drm/imx/dw_hdmi-imx.c However, the probe and remove functions are defined in a similar way to... drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c It would appear, looking at the vendor kernel code, that the configuration of the peripheral in the JZ4780 is most similar to that done in the i.MX products, with various configuration operations that are done in their own particular way in the vendor kernel code now being done in a more generic way in the bridge driver code. So, I have a certain amount of confidence that the PLL and current control tables are reasonable. == Observations == When powering up the system with the driver built into the kernel, the driver is able to obtain mode information over DDC using the Synopsys peripheral's own I2C support (which is more reliable than using the JZ4780's I2C peripherals), and a viable list of modes is obtained. However, the debugfs state information in /sys/kernel/debug/dri/0/state is largely unpopulated: plane[31]: plane-0 crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.000000x0.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range crtc[32]: crtc-0 enable=0 active=0 self_refresh_active=0 planes_changed=0 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=0 connector_mask=0 encoder_mask=0 mode: "": 0 0 0 0 0 0 0 0 0 0 0x0 0x0 connector[34]: HDMI-A-1 crtc=(null) self_refresh_aware=0 At the moment, I and others who have tried to test this code have seen that the peripheral is not enabled (as confirmed by inspecting the appropriate entry under /sys/devices/platform). It appears that one obstacle is that the "bus format" is not set for the connector. Here, I noticed (and was reminded again recently) that in the bridge driver, there is no call to drm_display_info_set_bus_formats unlike in other bridge drivers. If such a call is added with a plausible bus format, the peripheral will be enabled, but the signal is not correct (monitors report things like "Input not supported"). It also occurs to me that other aspects of the signal may need to be defined. However, the debugfs state information will be populated with plausible values and seems to indicate that initialisation has taken place. == Conclusions == Without direct modifications to dw-hdmi.c, it seems like the initialisation of the appropriate data structures is not being completed. Without the call to drm_display_info_set_bus_formats in dw_hdmi_bridge_attach, the encoder does not get set on the connector, and the chain of components is not fully traversed for initialisation. One part of this situation is the dw_hdmi_setup function in the bridge driver. Here, there is the following code: /* TOFIX: Get input format from plat data or fallback to RGB888 */ if (hdmi->plat_data->input_bus_format) hdmi->hdmi_data.enc_in_bus_format = hdmi->plat_data->input_bus_format; else hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24; /* TOFIX: Get input encoding from plat data or fallback to none */ if (hdmi->plat_data->input_bus_encoding) hdmi->hdmi_data.enc_in_encoding = hdmi->plat_data->input_bus_encoding; else hdmi->hdmi_data.enc_in_encoding = V4L2_YCBCR_ENC_DEFAULT; What I seek guidance on is whether the unfixed nature of this code is having an impact and what I should be doing to make this driver initialise correctly. Given that there is no obvious documentation for the Synopsys peripheral, I feel that it will be a long journey figuring this out by myself. Thanks for any advice that anyone might have! Paul [1] https://lists.freedesktop.org/archives/dri-devel/2017-March/134666.html [2] http://git.goldelico.com/?p=letux-kernel.git;a=blob_plain;f=drivers/gpu/drm…

5 25

← Newer
1
...
6
7
8
9
10
11
12
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020