kernel/linux.git/drivers/gpu/drm/Kconfig, branch v5.16.1

drm: fb_helper: improve CONFIG_FB dependency

2021-11-05T17:52:47+00:00

My previous patch correctly addressed the possible link failure, but as Jani points out, the dependency is now stricter than it needs to be. Change it again, to allow DRM_FBDEV_EMULATION to be used when DRM_KMS_HELPER and FB are both loadable modules and DRM is linked into the kernel. As a side-effect, the option is now only visible when at least one DRM driver makes use of DRM_KMS_HELPER. This is better, because the option has no effect otherwise. Fixes: 606b102876e3 ("drm: fb_helper: fix CONFIG_FB dependency") Suggested-by: Acked-by: Jani Nikula Reviewed-by: Javier Martinez Canillas Signed-off-by: Arnd Bergmann Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20211029120307.1407047-1-arnd@kernel.org

drm/locking: add backtrace for locking contended locks without backoff

2021-10-13T12:54:46+00:00

If drm_modeset_lock() returns -EDEADLK, the caller is supposed to drop all currently held locks using drm_modeset_backoff(). Failing to do so will result in warnings and backtraces on the paths trying to lock a contended lock. Add support for optionally printing the backtrace on the path that hit the deadlock and didn't gracefully handle the situation. For example, the patch [1] inadvertently dropped the return value check and error return on replacing calc_watermark_data() with intel_compute_global_watermarks(). The backtraces on the subsequent locking paths hitting WARN_ON(ctx->contended) were unhelpful, but adding the backtrace to the deadlock path produced this helpful printout: <7> [98.002465] drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x107/0x130 drm_atomic_get_plane_state+0x76/0x150 skl_compute_wm+0x251d/0x2b20 [i915] intel_atomic_check+0x1942/0x29e0 [i915] drm_atomic_check_only+0x554/0x910 drm_atomic_nonblocking_commit+0xe/0x50 drm_mode_atomic_ioctl+0x8c2/0xab0 drm_ioctl_kernel+0xac/0x140 Add new CONFIG_DRM_DEBUG_MODESET_LOCK to enable modeset lock debugging with stack depot and trace. [1] https://lore.kernel.org/r/20210924114741.15940-4-jani.nikula@intel.com v2: - default y if DEBUG_WW_MUTEX_SLOWPATH (Daniel) - depends on DEBUG_KERNEL Cc: Daniel Vetter Cc: Dave Airlie Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20211001091444.8177-1-jani.nikula@intel.com

drm: fb_helper: fix CONFIG_FB dependency

2021-10-01T07:40:16+00:00

With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper: aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function `drm_fb_helper_alloc_fbi': (.text+0x10cc): undefined reference to `framebuffer_alloc' Tighten the dependency so it is only allowed in the case that DRM can link against FB. Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB") Link: https://lore.kernel.org/all/20210721152211.2706171-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210927142816.2069269-1-arnd@kernel.org

Merge drm/drm-next into drm-misc-next

2021-09-14T07:25:30+00:00

Kickstart new drm-misc-next cycle. Signed-off-by: Maxime Ripard

drm: zte: remove obsolete DRM Support for ZTE SoCs

2021-08-26T09:19:08+00:00

Commit 89d4f98ae90d ("ARM: remove zte zx platform") removes the config ARCH_ZX. So, since then, the DRM Support for ZTE SoCs (config DRM_ZTE) depends on this removed config ARCH_ZX and cannot be selected. Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns: ARCH_ZX Referencing files: drivers/gpu/drm/zte/Kconfig So, remove this obsolete DRM support. Signed-off-by: Lukas Bulwahn Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210819112253.16484-5-lukas.bulwahn@gmail.com

drm: amdgpu: remove obsolete reference to config CHASH

2021-08-18T22:26:10+00:00

Commit 04ed8459f334 ("drm/amdgpu: remove chash") removes the chash architecture and its corresponding config CHASH. There is still a reference to CHASH in the config DRM_AMDGPU in ./drivers/gpu/drm/Kconfig. Remove this obsolete reference to config CHASH. Signed-off-by: Lukas Bulwahn Signed-off-by: Alex Deucher

drm/vgem: use shmem helpers

2021-08-12T19:41:10+00:00

Aside from deleting lots of code the real motivation here is to switch the mmap over to VM_PFNMAP, to be more consistent with what real gpu drivers do. They're all VM_PFNMAP, which means get_user_pages doesn't work, and even if you try and there's a struct page behind that, touching it and mucking around with its refcount can upset drivers real bad. v2: Review from Thomas: - sort #include - drop more dead code that I didn't spot somehow v3: select DRM_GEM_SHMEM_HELPER to make it build (intel-gfx-ci) v4: I got tricked by 0cf2ef46c6c0 ("drm/shmem-helper: Use cached mappings by default"), and we need WC in vgem because vgem doesn't have explicit begin/end cpu access ioctls. Also add a comment why exactly vgem has to use wc. v5: Don't set obj->base.funcs, it will default to drm_gem_shmem_funcs (Thomas) v6: vgem also needs an MMU for remapping v7: I absolutely butchered the rebases over the vgem mmap change and revert and broke the patch. Actually go back to v6 from before the vgem mmap changes. Cc: Thomas Zimmermann Acked-by: Thomas Zimmermann Cc: John Stultz Cc: Sumit Semwal Cc: "Christian König" Signed-off-by: Daniel Vetter Cc: Melissa Wen Cc: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20210812131412.2487363-4-daniel.vetter@ffwll.ch

drm/shmem-helper: Switch to vmf_insert_pfn

2021-08-12T19:41:10+00:00

We want to stop gup, which isn't the case if we use vmf_insert_page and VM_MIXEDMAP, because that does not set pte_special. The motivation here is to stop get_user_pages from working on buffer object mmaps in general. Quoting some discussion with Thomas: On Thu, Jul 22, 2021 at 08:22:43PM +0200, Thomas Zimmermann wrote: > Am 13.07.21 um 22:51 schrieb Daniel Vetter: > > We want to stop gup, which isn't the case if we use vmf_insert_page > > What is gup? get_user_pages. It pins memory wherever it is, which badly wreaks at least ttm and could also cause trouble with cma allocations. In both cases becaue we can't move/reuse these pages anymore. Now get_user_pages fails when the memory isn't considered "normal", like with VM_PFNMAP and using vm_insert_pfn. For consistency across all dma-buf I'm trying (together with Christian König) to roll this out everywhere, for fewer surprises. E.g. for 5.14 iirc we merged a patch to do the same for ttm, where it closes an actual bug (ttm gets really badly confused when there's suddenly pinned pages where it thought it can move them). cma allcoations already use VM_PFNMAP (because that's what dma_mmap is using underneath), as is anything that's using remap_pfn_range. Worst case we have to revert this patch for shmem helpers if it breaks something, but I hope that's not the case. On the ttm side we've also had some fallout that we needed to paper over with clever tricks. v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day) v3: add more depends on MMU. For usb drivers this is a bit awkward, but really it's correct: To be able to provide a contig mapping of buffers to userspace on !MMU platforms we'd need to use the cma helpers for these drivers on those platforms. As-is this wont work. Also not exactly sure why vm_insert_page doesn't go boom, because that definitely wont fly in practice since the pages are non-contig to begin with. v4: Explain the entire motivation a lot more (Thomas) Acked-by: Thomas Zimmermann Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210812131412.2487363-2-daniel.vetter@ffwll.ch

drm/bochs: Move to tiny/

2021-07-05T06:54:44+00:00

The bochs driver is only ~600 lines of code. Putting it into tiny/ cleans up the DRM directory slightly. Some style problems were fixed and unneeded include statements were removed. No functional changes. v2: * make bochs_mode_funcs static (Daniel, kernel test robot) * rebase onto aperture API changes Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210702075434.27677-2-tzimmermann@suse.de

drm: Introduce the DP AUX bus

2021-06-11T19:30:39+00:00

Historically "simple" eDP panels have been handled by panel-simple which is a basic platform_device. In the device tree, the panel node was at the top level and not connected to anything else. Let's change it so that, instead, panels can be represented as being children of the "DP AUX bus". Essentially we're saying that the hierarchy that we're going to represent is the "control" connections between devices. The DP AUX bus is a control bus provided by an eDP controller (the parent) and consumed by a device like a panel (the child). The primary incentive here is to cleanly provide the panel driver the ability to communicate over the AUX bus while handling lifetime issues properly. The panel driver may want the AUX bus for controlling the backlight or querying the panel's EDID. The idea for this bus's design was hashed out over IRC [1]. [1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-05-11 Cc: Laurent Pinchart Cc: Lyude Paul Cc: Rajeev Nandan Suggested-by: Laurent Pinchart Signed-off-by: Douglas Anderson Acked-by: Linus Walleij Reviewed-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.4.I787c9ba09ed5ce12500326ded73a4f7c9265b1b3@changeid