dri-devel March 2021

dri-devel@lists.freedesktop.org

326 participants
867 discussions

[PATCH v5 00/10] drm: rcar-du: Rework CRTC and groups for atomic commits
by Kieran Bingham 26 Mar '21

26 Mar '21

This patch series refactors atomic commit tail handling in the R-Car DU driver to simplify the code flow, and open the door to further optimisations. This iteration rebases the previous work and fixes a bug reported by the build bots. The R-Car DU is a bit of a strange beast, with support for up to four CRTCs that share resources in groups of two CRTCs. Depending on the generation, planes can be shared (on Gen 1 and Gen 2), and output routing configuration is also handled at the group level to some extent. Furthermore, many configuration parameters, especially those related to routing or clock handling, require the whole group to be restarted to take effect, even when the parameter itself affects a single CRTC only. This hardware architecture is difficult to handle properly on the software side, and has resulted in group usage being reference-counted while CRTC usage only tracks the enabled state. Calls are then unbalanced and difficult to trace, especially for the configuration of output routing, and implementation of new shared resources is hindered. This patch series aims at solving this problem. The series starts with 4 patches that touch the API between the DU and VSP drivers. It became apparent that we need to split the configuration of the VSP to allow fine grain control of setting the mode configuration and enabling/disabling of the pipeline. To support the cross-component API, the new interface is added in patch 01/10, including an implementation of vsp1_du_setup_lif() to support the transition. Patch 02/10 prepares for the new call flow that will call the atomic flush handler before enabling the pipeline. The DRM usage is adapted in patch 03/10, before the call is removed entirely in patch 04/10. The next two patches convert CRTC clock handling and initial setup, potentially called from both the CRTC .atomic_begin() and .atomic_enable() operations, to a simpler code flow controlled by the commit tail handler. Patch 05/10 takes the CRTCs out of standby and put them back in standby respectively at the beginning and end of the commit tail handler, based on the CRTC atomic state instead of state information stored in the custom rcar_du_crtc structure. Patch 06/10 then performs a similar change for the CRTC mode setting configuration. Finally, the last four patches introduce a DRM private object for the CRTC groups, along with an associated state. Patch 07/10 adds a helper macro to easily iterate over CRTC groups, and patch 08/10 adds the group private objects and empty states. Patches 09/10 and 10/10 respectively move the group setup and routing configuration under control of the commit tail handler, simplifying the configuration and moving state information from driver structures to state structures. More refactoring is expected, with plane assignment being moved to group states, and group restart being optimised to avoid flickering. Better configuration of pixel clocks could also be implemented on top of this series. The whole series has been tested on Salvator-XS with the DU test suite (http://git.ideasonboard.com/renesas/kms-tests.git). No failure or change in behaviour has been noticed. Kieran Bingham (8): media: vsp1: drm: Split vsp1_du_setup_lif() drm: rcar-du: Convert to the new VSP atomic API media: vsp1: drm: Remove vsp1_du_setup_lif() drm: rcar-du: Handle CRTC standby from commit tail handler drm: rcar-du: Handle CRTC configuration from commit tail handler drm: rcar-du: Provide for_each_group helper drm: rcar-du: Create a group state object drm: rcar-du: Perform group setup from the atomic tail handler Laurent Pinchart (2): media: vsp1: drm: Don't configure hardware when the pipeline is disabled drm: rcar-du: Centralise routing configuration in commit tail handler drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 160 ++++++---- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 9 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 6 +- drivers/gpu/drm/rcar-du/rcar_du_group.c | 390 +++++++++++++++++++----- drivers/gpu/drm/rcar-du/rcar_du_group.h | 44 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 63 ++-- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 10 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 20 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 3 + drivers/media/platform/vsp1/vsp1_drm.c | 188 ++++++++---- drivers/media/platform/vsp1/vsp1_drm.h | 2 + include/media/vsp1.h | 25 +- 12 files changed, 644 insertions(+), 276 deletions(-) -- 2.25.1

2 11

[PATCH 00/25] Rid W=1 warnings from HID
by Lee Jones 26 Mar '21

26 Mar '21

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (25): HID: intel-ish-hid: Remove unused variable 'err' HID: ishtp-hid-client: Move variable to where it's actually used HID: intel-ish-hid: pci-ish: Remove unused variable 'ret' HID: intel-ish: Supply some missing param descriptions HID: intel-ish: Fix a naming disparity and a formatting error HID: usbhid: Repair a formatting issue in a struct description HID: intel-ish-hid: Fix a little doc-rot HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses HID: hid-alps: Correct struct misnaming HID: intel-ish-hid: Fix potential copy/paste error HID: hid-core: Fix incorrect function name in header HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in header HID: ishtp-hid-client: Fix incorrect function name report_bad_packet() HID: hid-kye: Fix incorrect function name for kye_tablet_enable() HID: hid-picolcd_core: Remove unused variable 'ret' HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote abuses HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses HID: hid-uclogic-params: Ensure function names are present and correct in kernel-doc headers HID: hid-sensor-custom: Remove unused variable 'ret' HID: wacom_sys: Demote kernel-doc abuse HID: hid-sensor-hub: Remove unused struct member 'quirks' HID: hid-sensor-hub: Move 'hsdev' description to correct struct definition HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning drivers/hid/hid-alps.c | 2 +- drivers/hid/hid-core.c | 2 +- drivers/hid/hid-kye.c | 2 +- drivers/hid/hid-logitech-hidpp.c | 7 +-- drivers/hid/hid-picolcd_core.c | 5 +-- drivers/hid/hid-sensor-custom.c | 5 +-- drivers/hid/hid-sensor-hub.c | 4 +- drivers/hid/hid-thrustmaster.c | 24 +++++------ drivers/hid/hid-uclogic-params.c | 8 ++-- drivers/hid/hid-uclogic-rdesc.c | 2 +- drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +- drivers/hid/intel-ish-hid/ipc/pci-ish.c | 3 +- drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 45 ++++++++++---------- drivers/hid/intel-ish-hid/ishtp-hid-client.c | 11 +++-- drivers/hid/intel-ish-hid/ishtp-hid.c | 2 +- drivers/hid/intel-ish-hid/ishtp-hid.h | 9 +--- drivers/hid/intel-ish-hid/ishtp/bus.c | 9 +++- drivers/hid/intel-ish-hid/ishtp/client.c | 5 +-- drivers/hid/intel-ish-hid/ishtp/hbm.c | 4 +- drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h | 4 +- drivers/hid/usbhid/hid-pidff.c | 4 +- drivers/hid/usbhid/usbkbd.c | 2 +- drivers/hid/wacom_sys.c | 2 +- include/linux/intel-ish-client-if.h | 8 +++- 24 files changed, 90 insertions(+), 81 deletions(-) Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com> Cc: Anssi Hannula <anssi.hannula(a)gmail.com> Cc: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Cc: "Bruno Prémont" <bonbons(a)linux-vserver.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Daniel Drubin <daniel.drubin(a)intel.com> Cc: Dario Pagani <dario.pagani.146+linuxk(a)gmail.com> Cc: dri-devel(a)lists.freedesktop.org Cc: Henrik Rydberg <rydberg(a)bitmath.org> Cc: Jiri Kosina <jikos(a)kernel.org> Cc: Jonathan Cameron <jic23(a)kernel.org> Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Cc: Kim Kuparinen <kimi.h.kuparinen(a)gmail.com> Cc: "Krzysztof Wilczyński" <kw(a)linux.com> Cc: Lee Jones <lee.jones(a)linaro.org> Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-iio(a)vger.kernel.org Cc: linux-input(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: linux-stm32(a)st-md-mailman.stormreply.com Cc: linux-usb(a)vger.kernel.org Cc: Lopez Casado <nlopezcasad(a)logitech.com> Cc: "L. Vinyard, Jr" <rvinyard(a)cs.nmsu.edu> Cc: Masaki Ota <masaki.ota(a)jp.alps.com> Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com> Cc: message to <vojtech(a)ucw.cz> Cc: Michael Haboustak <mike-(a)cinci.rr.com> Cc: Rushikesh S Kadam <rushikesh.s.kadam(a)intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Uwe Kleine-König" <uwe(a)kleine-koenig.org> Cc: Vojtech Pavlik <vojtech(a)suse.cz> Cc: Zhang Lixu <lixu.zhang(a)intel.com> -- 2.27.0

3 4

[PULL] topic/i915-gem-next
by Daniel Vetter 26 Mar '21

26 Mar '21

Hi Dave, topic/i915-gem-next-2021-03-26: special i915-gem-next pull as requested - Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with help from Thomas Hellström) - watchdog (Tvrtko, one patch to cancel individual request from Chris) - legacy ioctl cleanup (Jason+Ashutosh) - i915-gem TODO and RFC process doc (me) - i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it and put it in here too After this it's back to normal drm-intel-gt-next pull request flow. The rough plan we discussed somewhat ad-hoc with Jani&Rodrigo (Joonas was out this week, but back next) is that they send out a pull with what's there right now. Then once both this branch here and the -gt-next pull are in drm-next they will backmerge, and the -gt-next tree is open for business again. Ofc new rules apply, anything that lands in there should be cc: dri-devel and reviewed there, but I think that's working fairly well already. Jani/Rodrigo/Joonas, can you pls send out internal mail once that's done since I'm on vacation next week? Also I want to thank Maarten for sticking around for well over a year with the dma_resv locking rework, it's a huge thing, tons of work, but finally we have it merged. Cheers, Daniel The following changes since commit 06debd6e1b28029e6e77c41e59a162868f377897: Merge tag 'drm-intel-next-2021-03-16' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-03-18 08:06:34 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/topic/i915-gem-next-2021-03-26 for you to fetch changes up to e1a5e6a8c48bf99ea374fb3e535661cfe226bca4: drm/doc: Add RFC section (2021-03-26 09:24:39 +0100) ---------------------------------------------------------------- special i915-gem-next pull as requested - Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with help from Thomas Hellström) - watchdog (Tvrtko, one patch to cancel individual request from Chris) - legacy ioctl cleanup (Jason+Ashutosh) - i915-gem TODO and RFC process doc (me) - i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it and put it in here too ---------------------------------------------------------------- Ashutosh Dixit (1): drm/i915: Disable pread/pwrite ioctl's for future platforms (v3) Chris Wilson (1): drm/i915: Individual request cancellation Daniel Vetter (2): drm/i915: add gem/gt TODO drm/doc: Add RFC section Jason Ekstrand (2): drm/i915/gem: Drop legacy execbuffer support (v2) drm/i915/gem: Drop relocation support on all new hardware (v6) Liam Howlett (1): i915_vma: Rename vma_lookup to i915_vma_lookup Maarten Lankhorst (62): drm/i915: Do not share hwsp across contexts any more, v8. drm/i915: Pin timeline map after first timeline pin, v4. drm/i915: Move cmd parser pinning to execbuffer drm/i915: Add missing -EDEADLK handling to execbuf pinning, v2. drm/i915: Ensure we hold the object mutex in pin correctly. drm/i915: Add gem object locking to madvise. drm/i915: Move HAS_STRUCT_PAGE to obj->flags drm/i915: Rework struct phys attachment handling drm/i915: Convert i915_gem_object_attach_phys() to ww locking, v2. drm/i915: make lockdep slightly happier about execbuf. drm/i915: Disable userptr pread/pwrite support. drm/i915: No longer allow exporting userptr through dma-buf drm/i915: Reject more ioctls for userptr, v2. drm/i915: Reject UNSYNCHRONIZED for userptr, v2. drm/i915: Make compilation of userptr code depend on MMU_NOTIFIER. drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7. drm/i915: Flatten obj->mm.lock drm/i915: Populate logical context during first pin. drm/i915: Make ring submission compatible with obj->mm.lock removal, v2. drm/i915: Handle ww locking in init_status_page drm/i915: Rework clflush to work correctly without obj->mm.lock. drm/i915: Pass ww ctx to intel_pin_to_display_plane drm/i915: Add object locking to vm_fault_cpu drm/i915: Move pinning to inside engine_wa_list_verify() drm/i915: Take reservation lock around i915_vma_pin. drm/i915: Make lrc_init_wa_ctx compatible with ww locking, v3. drm/i915: Make __engine_unpark() compatible with ww locking. drm/i915: Take obj lock around set_domain ioctl drm/i915: Defer pin calls in buffer pool until first use by caller. drm/i915: Fix pread/pwrite to work with new locking rules. drm/i915: Fix workarounds selftest, part 1 drm/i915: Add igt_spinner_pin() to allow for ww locking around spinner. drm/i915: Add ww locking around vm_access() drm/i915: Increase ww locking for perf. drm/i915: Lock ww in ucode objects correctly drm/i915: Add ww locking to dma-buf ops, v2. drm/i915: Add missing ww lock in intel_dsb_prepare. drm/i915: Fix ww locking in shmem_create_from_object drm/i915: Use a single page table lock for each gtt. drm/i915/selftests: Prepare huge_pages testcases for obj->mm.lock removal. drm/i915/selftests: Prepare client blit for obj->mm.lock removal. drm/i915/selftests: Prepare coherency tests for obj->mm.lock removal. drm/i915/selftests: Prepare context tests for obj->mm.lock removal. drm/i915/selftests: Prepare dma-buf tests for obj->mm.lock removal. drm/i915/selftests: Prepare execbuf tests for obj->mm.lock removal. drm/i915/selftests: Prepare mman testcases for obj->mm.lock removal. drm/i915/selftests: Prepare object tests for obj->mm.lock removal. drm/i915/selftests: Prepare object blit tests for obj->mm.lock removal. drm/i915/selftests: Prepare igt_gem_utils for obj->mm.lock removal drm/i915/selftests: Prepare context selftest for obj->mm.lock removal drm/i915/selftests: Prepare hangcheck for obj->mm.lock removal drm/i915/selftests: Prepare execlists and lrc selftests for obj->mm.lock removal drm/i915/selftests: Prepare mocs tests for obj->mm.lock removal drm/i915/selftests: Prepare ring submission for obj->mm.lock removal drm/i915/selftests: Prepare timeline tests for obj->mm.lock removal drm/i915/selftests: Prepare i915_request tests for obj->mm.lock removal drm/i915/selftests: Prepare memory region tests for obj->mm.lock removal drm/i915/selftests: Prepare cs engine tests for obj->mm.lock removal drm/i915/selftests: Prepare gtt tests for obj->mm.lock removal drm/i915: Finally remove obj->mm.lock. drm/i915: Keep userpointer bindings if seqcount is unchanged, v2. drm/i915: Move gt_revoke() slightly Thomas Hellström (1): drm/i915: Prepare for obj->mm.lock removal, v2. Tvrtko Ursulin (6): drm/i915: Extract active lookup engine to a helper drm/i915: Restrict sentinel requests further drm/i915: Handle async cancellation in sentinel assert drm/i915: Request watchdog infrastructure drm/i915: Fail too long user submissions by default drm/i915: Allow configuring default request expiry via modparam Documentation/gpu/index.rst | 1 + Documentation/gpu/rfc/index.rst | 17 + drivers/gpu/drm/i915/Kconfig.profile | 14 + drivers/gpu/drm/i915/Makefile | 1 - drivers/gpu/drm/i915/TODO.txt | 41 + drivers/gpu/drm/i915/display/intel_display.c | 71 +- drivers/gpu/drm/i915/display/intel_display.h | 2 +- drivers/gpu/drm/i915/display/intel_dsb.c | 2 +- drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +- drivers/gpu/drm/i915/display/intel_overlay.c | 34 +- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 73 +- drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 4 + drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 64 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 72 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 335 +++++--- drivers/gpu/drm/i915/gem/i915_gem_fence.c | 95 --- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 2 - drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 35 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 10 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 96 ++- drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 6 + drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 23 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 109 ++- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 110 ++- drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_region.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_region.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 39 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 39 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.h | 4 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 14 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 2 - drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 902 ++++++++------------- .../gpu/drm/i915/gem/selftests/huge_gem_object.c | 4 +- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 38 +- .../drm/i915/gem/selftests/i915_gem_client_blt.c | 8 +- .../drm/i915/gem/selftests/i915_gem_coherency.c | 14 +- .../gpu/drm/i915/gem/selftests/i915_gem_context.c | 10 +- .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- .../drm/i915/gem/selftests/i915_gem_execbuffer.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 21 +- .../gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_object_blt.c | 6 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c | 10 +- drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c | 2 +- drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen6_engine_cs.c | 8 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 13 +- drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 4 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 38 +- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 + .../gpu/drm/i915/gt/intel_execlists_submission.c | 49 +- .../gpu/drm/i915/gt/intel_execlists_submission.h | 2 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 10 +- drivers/gpu/drm/i915/gt/intel_gt.c | 3 + drivers/gpu/drm/i915/gt/intel_gt.h | 2 + drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 47 +- drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h | 5 + .../gpu/drm/i915/gt/intel_gt_buffer_pool_types.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_requests.c | 28 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 11 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 52 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 8 + drivers/gpu/drm/i915/gt/intel_lrc.c | 49 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 3 +- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c | 9 +- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 184 +++-- drivers/gpu/drm/i915/gt/intel_timeline.c | 426 +++------- drivers/gpu/drm/i915/gt/intel_timeline.h | 2 + drivers/gpu/drm/i915/gt/intel_timeline_types.h | 17 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +- drivers/gpu/drm/i915/gt/mock_engine.c | 22 +- drivers/gpu/drm/i915/gt/selftest_context.c | 4 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 9 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 23 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +- drivers/gpu/drm/i915/gt/selftest_lrc.c | 18 +- drivers/gpu/drm/i915/gt/selftest_mocs.c | 5 +- drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 4 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 177 ++-- drivers/gpu/drm/i915/gt/selftest_workarounds.c | 82 +- drivers/gpu/drm/i915/gt/shmem_utils.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 4 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +- drivers/gpu/drm/i915/i915_active.c | 20 +- drivers/gpu/drm/i915/i915_cmd_parser.c | 104 +-- drivers/gpu/drm/i915/i915_debugfs.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 18 +- drivers/gpu/drm/i915/i915_gem.c | 258 +++--- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- drivers/gpu/drm/i915/i915_memcpy.c | 2 +- drivers/gpu/drm/i915/i915_memcpy.h | 2 +- drivers/gpu/drm/i915/i915_params.c | 5 + drivers/gpu/drm/i915/i915_params.h | 1 + drivers/gpu/drm/i915/i915_perf.c | 56 +- drivers/gpu/drm/i915/i915_request.c | 133 ++- drivers/gpu/drm/i915/i915_request.h | 47 +- drivers/gpu/drm/i915/i915_selftest.h | 2 + drivers/gpu/drm/i915/i915_vma.c | 30 +- drivers/gpu/drm/i915/i915_vma.h | 20 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 94 ++- drivers/gpu/drm/i915/selftests/i915_request.c | 211 ++++- drivers/gpu/drm/i915/selftests/igt_spinner.c | 136 ++-- drivers/gpu/drm/i915/selftests/igt_spinner.h | 5 + .../gpu/drm/i915/selftests/intel_memory_region.c | 18 +- drivers/gpu/drm/i915/selftests/mock_region.c | 4 +- include/uapi/drm/i915_drm.h | 1 + 117 files changed, 2749 insertions(+), 2165 deletions(-) create mode 100644 Documentation/gpu/rfc/index.rst create mode 100644 drivers/gpu/drm/i915/TODO.txt delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_fence.c -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

2 2

[PATCHv2] drm/bridge: adv7511: fix support for large EDIDs
by Hans Verkuil 26 Mar '21

26 Mar '21

While testing support for large (> 256 bytes) EDIDs on the Renesas Koelsch board I noticed that the adv7511 bridge driver only read the first two blocks. The media V4L2 version for the adv7511 (drivers/media/i2c/adv7511-v4l2.c) handled this correctly. Besides a simple bug when setting the segment register (it was set to the block number instead of block / 2), the logic of the code was also weird. In particular reading the DDC_STATUS is odd: this is unrelated to EDID reading. The reworked code just waits for any EDID segment reads to finish (this does nothing if the a segment is already read), checks if the desired segment matches the read segment, and if not, then it requests the new segment and waits again for the EDID segment to be read. Finally it checks if the currently buffered EDID segment contains the desired EDID block, and if not it will update the EDID buffer from the adv7511. Tested with my Koelsch board and with EDIDs of 1, 2, 3 and 4 blocks. Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> --- Changes since v2: make current_edid_segment an int (it's set to -1 after all) and use that instead of reading ADV7511_REG_EDID_SEGMENT. Also sprinkle a few comments in the code. --- drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 40 +++++++++++++------- 2 files changed, 27 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h b/drivers/gpu/drm/bridge/adv7511/adv7511.h index a9bb734366ae..3dd29c578fc9 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h @@ -342,7 +342,7 @@ struct adv7511 { unsigned int f_audio; unsigned int audio_source; - unsigned int current_edid_segment; + int current_edid_segment; uint8_t edid_buf[256]; bool edid_read; diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 76555ae64e9c..43fefdd8d92b 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -327,7 +327,12 @@ static void adv7511_set_link_config(struct adv7511 *adv7511, static void __adv7511_power_on(struct adv7511 *adv7511) { + /* + * The adv7511 will start reading the first EDID segment as + * soon as it is powered on. + */ adv7511->current_edid_segment = -1; + adv7511->edid_read = false; regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, ADV7511_POWER_POWER_DOWN, 0); @@ -526,6 +531,7 @@ static int adv7511_wait_for_edid(struct adv7511 *adv7511, int timeout) static int adv7511_get_edid_block(void *data, u8 *buf, unsigned int block, size_t len) { + unsigned int need_segment = block / 2; struct adv7511 *adv7511 = data; struct i2c_msg xfer[2]; uint8_t offset; @@ -535,23 +541,29 @@ static int adv7511_get_edid_block(void *data, u8 *buf, unsigned int block, if (len > 128) return -EINVAL; - if (adv7511->current_edid_segment != block / 2) { - unsigned int status; + /* wait for any ongoing EDID segment reads to finish */ + adv7511_wait_for_edid(adv7511, 200); - ret = regmap_read(adv7511->regmap, ADV7511_REG_DDC_STATUS, - &status); + /* + * If the current read segment does not match what we need, then + * write the new segment and wait for it to be read. + * + * Note that after power on the adv7511 starts reading segment 0 + * of the EDID automatically. So if current_edid_segment < 0, then + * we do not need to write the EDID_SEGMENT register again, since + * it is already reading segment 0. + */ + if (adv7511->current_edid_segment >= 0 && + adv7511->current_edid_segment != need_segment) { + adv7511->edid_read = false; + regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT, + need_segment); + ret = adv7511_wait_for_edid(adv7511, 200); if (ret < 0) return ret; + } - if (status != 2) { - adv7511->edid_read = false; - regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT, - block); - ret = adv7511_wait_for_edid(adv7511, 200); - if (ret < 0) - return ret; - } - + if (adv7511->current_edid_segment != need_segment) { /* Break this apart, hopefully more I2C controllers will * support 64 byte transfers than 256 byte transfers */ @@ -579,7 +591,7 @@ static int adv7511_get_edid_block(void *data, u8 *buf, unsigned int block, offset += 64; } - adv7511->current_edid_segment = block / 2; + adv7511->current_edid_segment = need_segment; } if (block % 2 == 0) -- 2.30.1

1 0

[RFC PATCH 0/2] mm,drm/ttm: Always block GUP to TTM pages
by Thomas Hellström (Intel) 26 Mar '21

26 Mar '21

get_user_pages() to TTM pages is uwanted since TTM assumes it owns the pages exclusively and / or sets up page-table mappings to io memory. The first patch make sures we stop fast gup to huge TTM pages using a trick with pmd_devmap() and pud_devmap() without a backing dev_pagemap. The second patch makes sure we block normal gup by setting VM_PFNMAP Cc: Christian Koenig <christian.koenig(a)amd.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: linux-mm(a)kvack.org Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Thomas Hellström (Intel) <thomas_os(a)shipmail.org>

6 62

[PATCH] drm/bridge: adv7511: fix support for large EDIDs
by Hans Verkuil 26 Mar '21

26 Mar '21

While testing support for large (> 256 bytes) EDIDs on the Renesas Koelsch board I noticed that the adv7511 bridge driver only read the first two blocks. The media V4L2 version for the adv7511 (drivers/media/i2c/adv7511-v4l2.c) handled this correctly. Besides a simple bug when setting the segment register (it was set to the block number instead of block / 2), the logic of the code was also weird. In particular reading the DDC_STATUS is odd: this is unrelated to EDID reading. The reworked code just waits for any EDID segment reads to finish (this does nothing if the a segment is already read), checks if the desired segment matches the read segment, and if not, then it requests the new segment and waits again for the EDID segment to be read. Finally it checks if the currently buffered EDID segment contains the desired EDID block, and if not it will update the EDID buffer from the adv7511. Tested with my Koelsch board and with EDIDs of 1, 2, 3 and 4 blocks. Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> --- Testing on the Renesas board also requires these two adv7604 patches if you want to test with an HDMI cable between the HDMI input and output: https://patchwork.linuxtv.org/project/linux-media/patch/00882808-472a-d429-… https://patchwork.linuxtv.org/project/linux-media/patch/c7093e76-ffb4-b19c-… --- diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 76555ae64e9c..9e8db1c60167 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -328,6 +328,7 @@ static void adv7511_set_link_config(struct adv7511 *adv7511, static void __adv7511_power_on(struct adv7511 *adv7511) { adv7511->current_edid_segment = -1; + adv7511->edid_read = false; regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, ADV7511_POWER_POWER_DOWN, 0); @@ -529,29 +530,35 @@ static int adv7511_get_edid_block(void *data, u8 *buf, unsigned int block, struct adv7511 *adv7511 = data; struct i2c_msg xfer[2]; uint8_t offset; + unsigned int cur_segment; unsigned int i; int ret; if (len > 128) return -EINVAL; - if (adv7511->current_edid_segment != block / 2) { - unsigned int status; + /* wait for any EDID segment reads to finish */ + adv7511_wait_for_edid(adv7511, 200); - ret = regmap_read(adv7511->regmap, ADV7511_REG_DDC_STATUS, - &status); + ret = regmap_read(adv7511->regmap, ADV7511_REG_EDID_SEGMENT, &cur_segment); + if (ret < 0) + return ret; + + /* + * If the current read segment does not match what we need, then + * write the new segment and wait for it to be read. + */ + if (cur_segment != block / 2) { + adv7511->edid_read = false; + cur_segment = block / 2; + regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT, + cur_segment); + ret = adv7511_wait_for_edid(adv7511, 200); if (ret < 0) return ret; + } - if (status != 2) { - adv7511->edid_read = false; - regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT, - block); - ret = adv7511_wait_for_edid(adv7511, 200); - if (ret < 0) - return ret; - } - + if (adv7511->current_edid_segment != cur_segment) { /* Break this apart, hopefully more I2C controllers will * support 64 byte transfers than 256 byte transfers */ @@ -579,7 +586,7 @@ static int adv7511_get_edid_block(void *data, u8 *buf, unsigned int block, offset += 64; } - adv7511->current_edid_segment = block / 2; + adv7511->current_edid_segment = cur_segment; } if (block % 2 == 0)

3 5

[PATCH] drm/i915: Take request reference before arming the watchdog timer
by Tvrtko Ursulin 26 Mar '21

26 Mar '21

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Reference needs to be taken before arming the timer. Luckily, given the default timer period of 20s, the potential to hit the race is extremely unlikely. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Fixes: 9b4d0598ee94 ("drm/i915: Request watchdog infrastructure") Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- Test-with: 20210318162400.2065097-1-tvrtko.ursulin(a)linux.intel.com --- drivers/gpu/drm/i915/i915_request.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 9165971c3c47..bec9c3652188 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -350,6 +350,8 @@ static void __rq_arm_watchdog(struct i915_request *rq) if (!ce->watchdog.timeout_us) return; + i915_request_get(rq); + hrtimer_init(&wdg->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); wdg->timer.function = __rq_watchdog_expired; hrtimer_start_range_ns(&wdg->timer, @@ -357,7 +359,6 @@ static void __rq_arm_watchdog(struct i915_request *rq) NSEC_PER_USEC), NSEC_PER_MSEC, HRTIMER_MODE_REL); - i915_request_get(rq); } static void __rq_cancel_watchdog(struct i915_request *rq) -- 2.27.0

2 1

[PATCH] staging: fbtft: fix a typo
by Carlis 26 Mar '21

26 Mar '21

From: "Carlis" <zhangxuezhi1(a)yulong.com> Change 'tft' to 'TFT' Signed-off-by: Carlis <zhangxuezhi1(a)yulong.com> --- drivers/staging/fbtft/fbtft-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index 4f362da..44e7acb 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -775,7 +775,7 @@ void fbtft_framebuffer_release(struct fb_info *info) EXPORT_SYMBOL(fbtft_framebuffer_release); /** - * fbtft_register_framebuffer - registers a tft frame buffer device + * fbtft_register_framebuffer - registers a TFT frame buffer device * @fb_info: frame buffer info structure * * Sets SPI driverdata if needed @@ -873,7 +873,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info) EXPORT_SYMBOL(fbtft_register_framebuffer); /** - * fbtft_unregister_framebuffer - releases a tft frame buffer device + * fbtft_unregister_framebuffer - releases a TFT frame buffer device * @fb_info: frame buffer info structure * * Frees SPI driverdata if needed -- 1.9.1

3 4

[bug report] drm/ttm: switch to per device LRU lock
by Dan Carpenter 26 Mar '21

26 Mar '21

Hello Christian König, This is a semi-automatic email about new static checker warnings. The patch a1f091f8ef2b: "drm/ttm: switch to per device LRU lock" from Oct 6, 2020, leads to the following Smatch complaint: drivers/gpu/drm/ttm/ttm_bo.c:665 ttm_mem_evict_first() error: we previously assumed 'bo' could be null (see line 662) drivers/gpu/drm/ttm/ttm_bo.c 661 662 if (!bo) { ^^ "bo" is NULL 663 if (busy_bo && !ttm_bo_get_unless_zero(busy_bo)) 664 busy_bo = NULL; 665 spin_unlock(&bo->bdev->lru_lock); ^^^^^^^^^^^^^^^^^^ Dereference 666 ret = ttm_mem_evict_wait_busy(busy_bo, ctx, ticket); 667 if (busy_bo) regards, dan carpenter

1 0

[PATCH 1/2] drm/i915: add gem/gt TODO
by Daniel Vetter 26 Mar '21

26 Mar '21

We've discussed a bit how to get the gem/gt team better integrated and collaborate more with the wider community and agreed to the following: - all gem/gt patches are reviewed on dri-devel for now. That's overkill, but in the past there was definitely too little of that. - i915-gem folks are encouraged to cross review core patches from other teams - big features (especially uapi changes) need to be discussed in an rfc patch that documents the interface and big picture design, before we get lost in the details of the code - Also a rough TODO (can be refined as we go ofc) to get gem/gt back on track, like we've e.g. done with DAL/DC to get that in shape. v2: - add dma_fence annotations (Dave) - tasklet helpers (Jani on irc) There was also a discussion about moving these into gitlab issues, or gitlab issues as additional discussion place at least. For now it's just the TODO file Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Dave Airlie <airlied(a)redhat.com> Acked-by: Dave Airlie <airlied(a)redhat.com> Acked-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/i915/TODO.txt | 41 +++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 drivers/gpu/drm/i915/TODO.txt diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt new file mode 100644 index 000000000000..81a82c9c203f --- /dev/null +++ b/drivers/gpu/drm/i915/TODO.txt @@ -0,0 +1,41 @@ +gem/gt TODO items +----------------- + +- For discrete memory manager, merge enough dg1 to be able to refactor it to + TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has + improved a lot the past 2 years, there's no reason anymore not to use it. + +- Come up with a plan what to do with drm/scheduler and how to get there. + +- Roll out dma_fence critical section annotations. + +- There's a lot of complexity added past few years to make relocations faster. + That doesn't make sense given hw and gpu apis moved away from this model years + ago: + 1. Land a modern pre-bound uapi like VM_BIND + 2. Any complexity added in this area past few years which can't be justified + with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on + the bo and vm, plus some lru locks is all that needed. No complex rcu, + refcounts, caching, ... on everything. + This is the matching task on the vm side compared to ttm/dma_resv on the + backing storage side. + +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model. + How-to-dma_fence is core and drivers really shouldn't build their own world + here, treating everything else as a fixed platform. i915_sw_fence concepts + should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or + removed if dri-devel consensus is that it's not a good idea. Once that's done + maybe even remove it if there's nothing left. + +Smaller things: +- i915_utils.h needs to be moved to the right places. + +- dma_fence_work should be in drivers/dma-buf + +- i915_mm.c should be moved to the right places. Some of the helpers also look a + bit fishy: + + https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/ + +- tasklet helpers in i915_gem.h also look a bit misplaced and should + probably be moved to tasklet headers. -- 2.31.0

4 5

← Newer
1
...
28
29
30
31
32
33
34
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2021