dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[PATCH v3 0/3] NVIDIA Tegra NVDEC support
by Mikko Perttunen 20 Aug '21

20 Aug '21

Here's the v3 of the NVDEC support series, containing minor fixes compared to v2. NVDEC hardware documentation can be found at https://github.com/NVIDIA/open-gpu-doc/tree/master/classes/video and example userspace can be found at https://github.com/cyndis/vaapi-tegra-driver Thanks, Mikko Mikko Perttunen (3): dt-bindings: Add YAML bindings for NVDEC arm64: tegra: Add NVDEC to Tegra186/194 device trees drm/tegra: Add NVDEC driver .../gpu/host1x/nvidia,tegra210-nvdec.yaml | 109 ++++ MAINTAINERS | 1 + arch/arm64/boot/dts/nvidia/tegra186.dtsi | 16 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 36 ++ drivers/gpu/drm/tegra/Makefile | 3 +- drivers/gpu/drm/tegra/drm.c | 4 + drivers/gpu/drm/tegra/drm.h | 1 + drivers/gpu/drm/tegra/nvdec.c | 474 ++++++++++++++++++ drivers/gpu/host1x/dev.c | 18 + include/linux/host1x.h | 2 + 10 files changed, 663 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml create mode 100644 drivers/gpu/drm/tegra/nvdec.c -- 2.32.0

4 7

[GIT PULL] etnaviv-next for 5.15
by Lucas Stach 20 Aug '21

20 Aug '21

Hi Dave, Daniel, things are still slow in etnaviv land. Just one hardware support addition for the GPU found on the NXP Layerscape LS1028A SoC from Michael and the GEM mmap cleanup from Thomas. Regards, Lucas The following changes since commit 8a02ea42bc1d4c448caf1bab0e05899dad503f74: Merge tag 'drm-intel-next-fixes-2021-06-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-06-30 15:42:05 +1000) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux 81fd23e2b3ccf71c807e671444e8accaba98ca53 for you to fetch changes up to 81fd23e2b3ccf71c807e671444e8accaba98ca53: drm/etnaviv: Implement mmap as GEM object function (2021-07-06 18:32:23 +0200) ---------------------------------------------------------------- Michael Walle (2): drm/etnaviv: add HWDB entry for GC7000 r6202 drm/etnaviv: add clock gating workaround for GC7000 r6202 Thomas Zimmermann (1): drm/etnaviv: Implement mmap as GEM object function drivers/gpu/drm/etnaviv/etnaviv_drv.c | 14 ++------------ drivers/gpu/drm/etnaviv/etnaviv_drv.h | 3 --- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 18 +++++------------- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 ------------- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++++++ drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 +++++++++++++++++++++++++++++++ 6 files changed, 44 insertions(+), 41 deletions(-)

1 0

[pull] amdgpu, amdkfd, radeon drm-next-5.15
by Alex Deucher 20 Aug '21

20 Aug '21

Hi Dave, Daniel, Updates for 5.15. Mainly bug fixes and cleanups. The following changes since commit 554594567b1fa3da74f88ec7b2dc83d000c58e98: drm/display: fix possible null-pointer dereference in dcn10_set_clock() (2021-08-11 17:19:54 -0400) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.15-2021-08-20 for you to fetch changes up to 90a9266269eb9f71af1f323c33e1dca53527bd22: drm/amdgpu: Cancel delayed work when GFXOFF is disabled (2021-08-20 12:09:44 -0400) ---------------------------------------------------------------- amd-drm-next-5.15-2021-08-20: amdgpu: - embed hw fence into job - Misc SMU fixes - PSP TA code cleanup - RAS fixes - PWM fan speed fixes - DC workqueue cleanups - SR-IOV fixes - gfxoff delayed work fix - Pin domain check fix amdkfd: - SVM fixes radeon: - Code cleanup ---------------------------------------------------------------- Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.79 Aric Cyr (1): drm/amd/display: 3.2.149 Candice Li (3): drm/amd/amdgpu: consolidate PSP TA context drm/amd/amdgpu: remove unnecessary RAS context field drm/amd: consolidate TA shared memory structures Christian König (1): drm/amdgpu: use the preferred pin domain after the check Colin Ian King (1): drm/amd/pm: Fix spelling mistake "firwmare" -> "firmware" Evan Quan (9): drm/amd/pm: correct the fan speed RPM setting drm/amd/pm: record the RPM and PWM based fan speed settings drm/amd/pm: correct the fan speed PWM retrieving drm/amd/pm: correct the fan speed RPM retrieving drm/amd/pm: drop the unnecessary intermediate percent-based transition drm/amd/pm: drop unnecessary manual mode check drm/amd/pm: correct the address of Arcturus fan related registers drm/amdgpu: disable BACO support for 699F:C7 polaris12 SKU temporarily drm/amd/pm: a quick fix for "divided by zero" error Hawking Zhang (1): drm/amdgpu: increase max xgmi physical node for aldebaran Jack Zhang (1): drm/amd/amdgpu embed hw_fence into amdgpu_job Jake Wang (1): drm/amd/display: Ensure DCN save after VM setup Jiange Zhao (1): drm/amdgpu: Add MB_REQ_MSG_READY_TO_RESET response when VF get FLR notification. Jonathan Kim (1): drm/amdgpu: get extended xgmi topology data Kenneth Feng (2): Revert "drm/amd/pm: fix workload mismatch on vega10" drm/amd/pm: change the workload type for some cards Kevin Wang (5): drm/amd/pm: correct DPM_XGMI/VCN_DPM feature name drm/amd/pm: skip to load smu microcode on sriov for aldebaran drm/amd/pm: change return value in aldebaran_get_power_limit() drm/amd/pm: change smu msg's attribute to allow working under sriov drm/amd/pm: change pp_dpm_sclk/mclk/fclk attribute is RO for aldebaran Lukas Bulwahn (1): drm: amdgpu: remove obsolete reference to config CHASH Michel Dänzer (1): drm/amdgpu: Cancel delayed work when GFXOFF is disabled Nathan Chancellor (1): drm/radeon: Add break to switch statement in radeonfb_create_pinned_object() Nicholas Kazlauskas (3): drm/amd/display: Fix multi-display support for idle opt workqueue drm/amd/display: Use vblank control events for PSR enable/disable drm/amd/display: Guard vblank wq flush with DCN guards Wayne Lin (1): drm/amd/display: Create dc_sink when EDID fail Yifan Zhang (1): drm/amdkfd: fix random KFDSVMRangeTest.SetGetAttributesTest test failure YuBiao Wang (1): drm/amd/amdgpu:flush ttm delayed work before cancel_sync Zhan Liu (1): drm/amd/display: Use DCN30 watermark calc for DCN301 Zhigang Luo (1): drm/amdgpu: correct MMSCH 1.0 version drivers/gpu/drm/Kconfig | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 28 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 86 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 37 +- drivers/gpu/drm/amd/amdgpu/amdgpu_hdp.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 39 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mmhub.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 432 ++++++++++++--------- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 111 ++---- drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 59 ++- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c | 5 +- drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h | 4 +- drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 2 + drivers/gpu/drm/amd/amdgpu/mxgpu_nv.h | 3 +- drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 4 +- drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 40 +- drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 28 +- drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 24 +- drivers/gpu/drm/amd/amdgpu/ta_xgmi_if.h | 3 +- drivers/gpu/drm/amd/amdgpu/vi.c | 9 +- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 8 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 112 +++--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 23 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 12 +- .../amd/display/amdgpu_dm/amdgpu_dm_irq_params.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 23 ++ drivers/gpu/drm/amd/display/dc/core/dc.c | 6 + drivers/gpu/drm/amd/display/dc/core/dc_vm_helper.c | 3 + drivers/gpu/drm/amd/display/dc/dc.h | 3 +- .../drm/amd/display/dc/dcn301/dcn301_resource.c | 96 +---- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c | 12 + drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.h | 1 + drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 1 + drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h | 1 + drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 19 +- .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c | 56 +-- .../amd/include/asic_reg/thm/thm_11_0_2_offset.h | 6 + .../amd/include/asic_reg/thm/thm_11_0_2_sh_mask.h | 3 + drivers/gpu/drm/amd/include/kgd_pp_interface.h | 4 +- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 32 +- drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 8 +- drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h | 25 +- drivers/gpu/drm/amd/pm/inc/hwmgr.h | 6 +- drivers/gpu/drm/amd/pm/inc/smu_types.h | 1 - drivers/gpu/drm/amd/pm/inc/smu_v11_0.h | 11 +- drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 16 +- .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 8 +- .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.c | 21 +- .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.h | 4 +- .../gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 21 +- .../drm/amd/pm/powerplay/hwmgr/vega10_thermal.c | 18 +- .../drm/amd/pm/powerplay/hwmgr/vega10_thermal.h | 4 +- .../gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c | 6 +- .../drm/amd/pm/powerplay/hwmgr/vega20_thermal.c | 30 +- .../drm/amd/pm/powerplay/hwmgr/vega20_thermal.h | 4 +- drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 19 +- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 81 ++-- drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 174 ++++++++- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 28 +- .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 33 +- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 107 ++++- drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 23 +- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 102 +++-- drivers/gpu/drm/radeon/radeon_fb.c | 1 + 83 files changed, 1346 insertions(+), 848 deletions(-)

1 0

[PATCH v2 0/8] drm/bridge: Make panel and bridge probe order consistent
by Maxime Ripard 20 Aug '21

20 Aug '21

Hi, We've encountered an issue with the RaspberryPi DSI panel that prevented the whole display driver from probing. The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi: Only register our component once a DSI device is attached"), but the basic idea is that since the panel is probed through i2c, there's no synchronization between its probe and the registration of the MIPI-DSI host it's attached to. We initially moved the component framework registration to the MIPI-DSI Host attach hook to make sure we register our component only when we have a DSI device attached to our MIPI-DSI host, and then use lookup our DSI device in our bind hook. However, all the DSI bridges controlled through i2c are only registering their associated DSI device in their bridge attach hook, meaning with our change above, we never got that far, and therefore ended up in the same situation than the one we were trying to fix for panels. Since the RaspberryPi panel is the only driver in that situation, whereas it seems like there's a consensus in bridge drivers, it makes more sense to try to mimic the bridge pattern in the panel driver. However, panels don't have an attach hook, and adding more panel hooks would lead to more path to maintain in each and every driver, while the general push is towards bridges. We also have to make sure that each and every DSI host and device driver behaves the same in order to have expectations to rely on. The solution I'm proposing is thus done in several steps: - We get rid of the initial patch to make sure we support the bridge case, and not the odd-panel one. - Add a function that returns a bridge from a DT node, reducing the amount of churn in each and every driver and making it a real incentive to not care about panels in display drivers but only bridges. - Add an attach and detach hook into the panel operations, and make it called automatically by the DRM panel bridge. - Convert the VC4 DSI host to this new bridge function, and the RaspberryPi Panel to the new attach and detach hooks. If the general approach is agreed upon, other drivers will obviously be converted to drm_of_get_next. Let me know what you think, Maxime --- Changes from v1: - Change the name of drm_of_get_next function to drm_of_get_bridge - Mention the revert of 87154ff86bf6 and squash the two patches that were reverting that commit - Add some documentation - Make drm_panel_attach and _detach succeed when no callback is there Maxime Ripard (8): Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" drm/bridge: Add a function to abstract away panels drm/bridge: Add documentation sections drm/bridge: Document the probe issue with MIPI-DSI bridges drm/panel: Create attach and detach callbacks drm/vc4: dsi: Switch to drm_of_get_bridge drm/panel: raspberrypi-touchscreen: Use the attach hook drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver Documentation/gpu/drm-kms-helpers.rst | 12 ++ drivers/gpu/drm/bridge/panel.c | 6 + drivers/gpu/drm/drm_bridge.c | 114 ++++++++++++- drivers/gpu/drm/drm_of.c | 3 + drivers/gpu/drm/drm_panel.c | 47 ++++++ .../drm/panel/panel-raspberrypi-touchscreen.c | 158 +++++++++--------- drivers/gpu/drm/vc4/vc4_drv.c | 2 + drivers/gpu/drm/vc4/vc4_dsi.c | 53 +++--- include/drm/drm_bridge.h | 2 + include/drm/drm_panel.h | 27 +++ 10 files changed, 303 insertions(+), 121 deletions(-) -- 2.31.1

4 12

[PATCH] drm/i915/gt: Potential error pointer dereference in pinned_context()
by Dan Carpenter 20 Aug '21

20 Aug '21

If the intel_engine_create_pinned_context() function returns an error pointer, then dereferencing "ce" will Oops. Use "vm" instead of "ce->vm". Fixes: cf586021642d ("drm/i915/gt: Pipelined page migration") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index d0a7c934fd3b..1dac21aa7e5c 100644 --- a/drivers/gpu/drm/i915/gt/intel_migrate.c +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c @@ -177,7 +177,7 @@ static struct intel_context *pinned_context(struct intel_gt *gt) ce = intel_engine_create_pinned_context(engine, vm, SZ_512K, I915_GEM_HWS_MIGRATE, &key, "migrate"); - i915_vm_put(ce->vm); + i915_vm_put(vm); return ce; } -- 2.20.1

3 2

[PATCH v2 00/14] drm: Make DRM's IRQ helpers legacy
by Thomas Zimmermann 20 Aug '21

20 Aug '21

DRM's IRQ helpers are only helpful for old, non-KMS drivers. Move the code behind CONFIG_DRM_LEGACY. Convert KMS drivers to Linux IRQ interfaces. DRM provides IRQ helpers for setting up, receiving and removing IRQ handlers. It's an abstraction over plain Linux functions. The code is mid-layerish with several callbacks to hook into the rsp drivers. Old UMS driver have their interrupts enabled via ioctl, so these abstractions makes some sense. Modern KMS manage all their interrupts internally. Using the DRM helpers adds indirection without benefits. Most KMS drivers already use Linux IRQ functions instead of DRM's abstraction layer. Patches 1 to 12 convert the remaining ones. The patches also resolve a bug for devices without assigned interrupt number. DRM helpers don't test for IRQ_NOTCONNECTED, so drivers do not detect if the device has no interrupt assigned. Patch 13 removes an unused function. Patch 14 moves the DRM IRQ helpers behind CONFIG_DRM_LEGACY. Only the old non-KMS drivers still use the functionality. v2: * drop IRQ_NOTCONNECTED test from atmel-hlcdc (Sam) * use devm_request_irq() in atmel-hlcdc (Sam) * unify variable names in arm/hlcdc (Sam) Thomas Zimmermann (14): drm/amdgpu: Convert to Linux IRQ interfaces drm/arm/hdlcd: Convert to Linux IRQ interfaces drm/atmel-hlcdc: Convert to Linux IRQ interfaces drm/fsl-dcu: Convert to Linux IRQ interfaces drm/gma500: Convert to Linux IRQ interfaces drm/kmb: Convert to Linux IRQ interfaces drm/msm: Convert to Linux IRQ interfaces drm/mxsfb: Convert to Linux IRQ interfaces drm/radeon: Convert to Linux IRQ interfaces drm/tidss: Convert to Linux IRQ interfaces drm/tilcdc: Convert to Linux IRQ interfaces drm/vc4: Convert to Linux IRQ interfaces drm: Remove unused devm_drm_irq_install() drm: IRQ midlayer is now legacy drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 21 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 174 ++++++++++--------- drivers/gpu/drm/arm/hdlcd_drv.h | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 80 +++++---- drivers/gpu/drm/drm_irq.c | 95 +--------- drivers/gpu/drm/drm_legacy_misc.c | 3 +- drivers/gpu/drm/drm_vblank.c | 8 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 78 +++++---- drivers/gpu/drm/gma500/power.c | 1 + drivers/gpu/drm/gma500/psb_drv.c | 8 +- drivers/gpu/drm/gma500/psb_drv.h | 5 - drivers/gpu/drm/gma500/psb_irq.c | 26 ++- drivers/gpu/drm/gma500/psb_irq.h | 4 +- drivers/gpu/drm/i810/i810_dma.c | 3 +- drivers/gpu/drm/kmb/kmb_drv.c | 26 ++- drivers/gpu/drm/mga/mga_dma.c | 2 +- drivers/gpu/drm/mga/mga_drv.h | 1 - drivers/gpu/drm/msm/msm_drv.c | 113 +++++++----- drivers/gpu/drm/msm/msm_kms.h | 2 +- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 81 +++++---- drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 + drivers/gpu/drm/r128/r128_cce.c | 3 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 - drivers/gpu/drm/radeon/radeon_irq_kms.c | 44 ++++- drivers/gpu/drm/radeon/radeon_kms.h | 4 - drivers/gpu/drm/tidss/tidss_drv.c | 15 +- drivers/gpu/drm/tidss/tidss_drv.h | 2 + drivers/gpu/drm/tidss/tidss_irq.c | 27 ++- drivers/gpu/drm/tidss/tidss_irq.h | 4 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 51 ++++-- drivers/gpu/drm/tilcdc/tilcdc_drv.h | 3 + drivers/gpu/drm/vc4/vc4_drv.c | 4 - drivers/gpu/drm/vc4/vc4_drv.h | 8 +- drivers/gpu/drm/vc4/vc4_irq.c | 48 +++-- drivers/gpu/drm/vc4/vc4_v3d.c | 17 +- drivers/gpu/drm/via/via_mm.c | 3 +- include/drm/drm_device.h | 18 +- include/drm/drm_drv.h | 44 +---- include/drm/drm_irq.h | 32 ---- include/drm/drm_legacy.h | 3 + 42 files changed, 567 insertions(+), 504 deletions(-) delete mode 100644 include/drm/drm_irq.h base-commit: c9d6903562aa335593daf44b4a1edeaef6bf9206 prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24 prerequisite-patch-id: c3f32630e1d2de2eb74316c930578847d4b83fb3 prerequisite-patch-id: b32ca0abfc255601f8a5052d3b88be09527dabcb prerequisite-patch-id: 22a3f264168bacb04ef65306b32b86be8dc982ef prerequisite-patch-id: 095a0acb604eb02956e1a7e53da41371c64eb813 prerequisite-patch-id: 7a2417d5d8d453204bd94aa873e3faae812f26fc -- 2.32.0

7 29

[PATCH v4 0/5] drm: update locking for modesetting
by Desmond Cheong Zhi Xi 20 Aug '21

20 Aug '21

Hi, Thanks for all the helpful feedback on the previous version. Taking all the suggestions together, this series now converts drm_device.master_mutex into master_rwsem, and also attempts to remove drm_file.master_lookup_lock. There might still be lock inversions lurking, so the output from Intel-gfx CI should be interesting to see. Overall, this series makes the following changes: - Patch 1: Fix a potential null ptr dereference in drm_master_release - Patch 2: Convert master_mutex into rwsem (avoids creating a new lock) - Patch 3: Update global mutex locking in the ioctl handler (avoids deadlock when grabbing read lock on master_rwsem in drm_ioctl_kernel) - Patch 4: Plug races with drm modesetting rights - Patch 5: Replace master_lookup_lock with master_rwsem by untangling remaining lock hierarchy inversions v3 -> v4 (suggested by Daniel Vetter): - Drop a patch that added an unnecessary master_lookup_lock in drm_master_release (previously patch 2) - Drop a patch that addressed a non-existent race in drm_is_current_master_locked (previously patch 3) - Remove fixes for non-existent null ptr dereferences (previous patch 4) - Protect drm_master.magic_map,unique{_len} with master_rwsem instead of master_lookup_lock (dropped previous patch 5) - Drop the patch that moved master_lookup_lock into struct drm_device (previously patch 1) - Drop a patch to export task_work_add (previously patch 8) - Revert the check for the global mutex in the ioctl handler to use drm_core_check_feature instead of drm_dev_needs_global_mutex - Push down master_rwsem locking for selected ioctls to avoid lock hierarchy inversions, and to allow us to hold write locks on master_rwsem instead of flushing readers - Remove master_lookup_lock by replacing it with master_rwsem v2 -> v3: - Unexport drm_master_flush, as suggested by Daniel Vetter. - Merge master_mutex and master_rwsem, as suggested by Daniel Vetter. - Export task_work_add, reported by kernel test robot. - Make master_flush static, reported by kernel test robot. - Move master_lookup_lock into struct drm_device. - Add a missing lock on master_lookup_lock in drm_master_release. - Fix a potential race in drm_is_current_master_locked. - Fix potential null ptr dereferences in drm_{auth, ioctl}. - Protect magic_map,unique{_len} with master_lookup_lock. - Convert master_mutex into a rwsem. - Update global mutex locking in the ioctl handler. v1 -> v2 (suggested by Daniel Vetter): - Address an additional race when drm_open runs. - Switch from SRCU to rwsem to synchronise readers and writers. - Implement drm_master_flush with task_work so that flushes can be queued to run before returning to userspace without creating a new DRM_MASTER_FLUSH ioctl flag. Best wishes, Desmond Desmond Cheong Zhi Xi (5): drm: fix null ptr dereference in drm_master_release drm: convert drm_device.master_mutex into a rwsem drm: lock drm_global_mutex earlier in the ioctl handler drm: avoid races with modesetting rights drm: remove drm_file.master_lookup_lock drivers/gpu/drm/drm_auth.c | 54 ++++++++++++------------ drivers/gpu/drm/drm_debugfs.c | 4 +- drivers/gpu/drm/drm_drv.c | 3 +- drivers/gpu/drm/drm_file.c | 7 ++-- drivers/gpu/drm/drm_internal.h | 1 + drivers/gpu/drm/drm_ioctl.c | 48 ++++++++++++--------- drivers/gpu/drm/drm_lease.c | 69 ++++++++++++++----------------- drivers/gpu/drm/drm_mode_object.c | 14 +++++-- include/drm/drm_auth.h | 6 +-- include/drm/drm_device.h | 15 +++++-- include/drm/drm_file.h | 17 +++----- include/drm/drm_lease.h | 2 +- 12 files changed, 125 insertions(+), 115 deletions(-) -- 2.25.1

1 5

[PATCH v3] Revert "drm/scheduler: Avoid accessing freed bad job."
by Jingwen Chen 20 Aug '21

20 Aug '21

[Why] for bailing job, this commit will delete it from pending list thus the bailing job will never have a chance to be resubmitted even in advance tdr mode. [How] after embeded hw_fence into amdgpu_job is done, the race condition that this commit tries to work around is completely solved.So revert this commit. This reverts commit 135517d3565b48f4def3b1b82008bc17eb5d1c90. v2: add dma_fence_get/put() around timedout_job to avoid concurrent delete during processing timedout_job v3: park sched->thread instead during timedout_job. Signed-off-by: Jingwen Chen <Jingwen.Chen2(a)amd.com> --- drivers/gpu/drm/scheduler/sched_main.c | 22 ++-------------------- 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index a2a953693b45..c187fd3a6bb6 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -319,17 +319,12 @@ static void drm_sched_job_timedout(struct work_struct *work) sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work); /* Protects against concurrent deletion in drm_sched_get_cleanup_job */ + kthread_park(sched->thread); spin_lock(&sched->job_list_lock); job = list_first_entry_or_null(&sched->pending_list, struct drm_sched_job, list); if (job) { - /* - * Remove the bad job so it cannot be freed by concurrent - * drm_sched_cleanup_jobs. It will be reinserted back after sched->thread - * is parked at which point it's safe. - */ - list_del_init(&job->list); spin_unlock(&sched->job_list_lock); status = job->sched->ops->timedout_job(job); @@ -345,6 +340,7 @@ static void drm_sched_job_timedout(struct work_struct *work) } else { spin_unlock(&sched->job_list_lock); } + kthread_unpark(sched->thread); if (status != DRM_GPU_SCHED_STAT_ENODEV) { spin_lock(&sched->job_list_lock); @@ -392,20 +388,6 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad) kthread_park(sched->thread); - /* - * Reinsert back the bad job here - now it's safe as - * drm_sched_get_cleanup_job cannot race against us and release the - * bad job at this point - we parked (waited for) any in progress - * (earlier) cleanups and drm_sched_get_cleanup_job will not be called - * now until the scheduler thread is unparked. - */ - if (bad && bad->sched == sched) - /* - * Add at the head of the queue to reflect it was the earliest - * job extracted. - */ - list_add(&bad->list, &sched->pending_list); - /* * Iterate the job list from later to earlier one and either deactive * their HW callbacks or remove them from pending list if they already -- 2.25.1

1 0

Re: [PATCH v6 08/13] mm: call pgmap->ops->page_free for DEVICE_GENERIC pages
by Jerome Glisse 20 Aug '21

20 Aug '21

On Thu, Aug 19, 2021 at 10:05 PM Christoph Hellwig <hch(a)lst.de> wrote: > > On Tue, Aug 17, 2021 at 11:44:54AM -0400, Felix Kuehling wrote: > > >> That's a good catch. Existing drivers shouldn't need a page_free > > >> callback if they didn't have one before. That means we need to add a > > >> NULL-pointer check in free_device_page. > > > Also the other state clearing (__ClearPageWaiters/mem_cgroup_uncharge/ > > > ->mapping = NULL). > > > > > > In many ways this seems like you want to bring back the DEVICE_PUBLIC > > > pgmap type that was removed a while ago due to the lack of users > > > instead of overloading the generic type. > > > > I think so. I'm not clear about how DEVICE_PUBLIC differed from what > > DEVICE_GENERIC is today. As I understand it, DEVICE_PUBLIC was removed > > because it was unused and also known to be broken in some ways. > > DEVICE_GENERIC seemed close enough to what we need, other than not being > > supported in the migration helpers. > > > > Would you see benefit in re-introducing DEVICE_PUBLIC as a distinct > > memory type from DEVICE_GENERIC? What would be the benefits of making > > that distinction? > > The old DEVICE_PUBLIC mostly different in that it allowed the page > to be returned from vm_normal_page, which I think was horribly buggy. Why was that buggy ? If I were to do it now, i would return DEVICE_PUBLIC page from vm_normal_page but i would ban pinning as pinning is exceptionally wrong for GPU. If you migrate some random anonymous/file back to your GPU memory and it gets pinned there then there is no way for the GPU to migrate the page out. Quickly you will run out of physically contiguous memory and things like big graphic buffer allocation (anything that needs physically contiguous memory) will fail. It is less of an issue on some hardware that rely less and less on physically contiguous memory but i do not think it is completely gone from all hw. > But the point is not to bring back these old semantics. The idea > is to be able to differeniate between your new coherent on-device > memory and the existing DEVICE_GENERIC. That is call the > code in free_devmap_managed_page that is currently only used > for device private pages also for your new public device pages without > affecting the devdax and xen use cases. Yes, I would rather bring back DEVICE_PUBLIC then try to use DEVICE_GENERIC, the GENERIC change was done for users that closely matched DAX semantics and it is not the case here, at least not from my point of view. Jerome

1 0

[PATCH v6 00/13] Support DEVICE_GENERIC memory in migrate_vma_*
by Alex Sierra 20 Aug '21

20 Aug '21

v1: AMD is building a system architecture for the Frontier supercomputer with a coherent interconnect between CPUs and GPUs. This hardware architecture allows the CPUs to coherently access GPU device memory. We have hardware in our labs and we are working with our partner HPE on the BIOS, firmware and software for delivery to the DOE. The system BIOS advertises the GPU device memory (aka VRAM) as SPM (special purpose memory) in the UEFI system address map. The amdgpu driver looks it up with lookup_resource and registers it with devmap as MEMORY_DEVICE_GENERIC using devm_memremap_pages. Now we're trying to migrate data to and from that memory using the migrate_vma_* helpers so we can support page-based migration in our unified memory allocations, while also supporting CPU access to those pages. This patch series makes a few changes to make MEMORY_DEVICE_GENERIC pages behave correctly in the migrate_vma_* helpers. We are looking for feedback about this approach. If we're close, what's needed to make our patches acceptable upstream? If we're not close, any suggestions how else to achieve what we are trying to do (i.e. page migration and coherent CPU access to VRAM)? This work is based on HMM and our SVM memory manager that was recently upstreamed to Dave Airlie's drm-next branch https://cgit.freedesktop.org/drm/drm/log/?h=drm-next On top of that we did some rework of our VRAM management for migrations to remove some incorrect assumptions, allow partially successful migrations and GPU memory mappings that mix pages in VRAM and system memory. https://lore.kernel.org/dri-devel/20210527205606.2660-6-Felix.Kuehling@amd.… v2: This patch series version has merged "[RFC PATCH v3 0/2] mm: remove extra ZONE_DEVICE struct page refcount" patch series made by Ralph Campbell. It also applies at the top of these series, our changes to support device generic type in migration_vma helpers. This has been tested in systems with device memory that has coherent access by CPU. Also addresses the following feedback made in v1: - Isolate in one patch kernel/resource.c modification, based on Christoph's feedback. - Add helpers check for generic and private type to avoid duplicated long lines. v3: - Include cover letter from v1. - Rename dax_layout_is_idle_page func to dax_page_unused in patch ext4/xfs: add page refcount helper. v4: - Add support for zone device generic type in lib/test_hmm and tool/testing/selftest/vm/hmm-tests. - Add missing page refcount helper to fuse/dax.c. This was included in one of Ralph Campbell's patches. v5: - Cosmetic changes on patches 3, 5 and 13 - A bug was found while running one of the xfstest (generic/413) used to validate fs_dax device type. This was first introduced by patch: "mm: remove extra ZONE_DEVICE struct page refcount" whic is part of these patch series. The bug was showed as WARNING message at try_grab_page function call, due to a page refcounter equal to zero. Part of "mm: remove extra ZONE_DEVICE struct page refcount" changes, was to initialize page refcounter to zero. Therefore, a special condition was added to try_grab_page on this v5, were it checks for device zone pages too. It is included in the same patch. This is how mm changes from these patch series have been validated: - hmm-tests were run using device private and device generic types. This last, just added in these patch series. efi_fake_mem was used to mimic SPM memory for device generic. - xfstests tool was used to validate fs-dax device type and page refcounter changes. DAX configuration was used along with emulated Persisten Memory set as memmap=4G!4G memmap=4G!9G. xfstests were run from ext4 and generic lists. Some of them, did not run due to limitations in configuration. Ex. test not supporting specific file system or DAX mode. Only three tests failed, generic/356/357 and ext4/049. However, these failures were consistent before and after applying these patch series. xfstest configuration: TEST_DEV=/dev/pmem0 TEST_DIR=/mnt/ram0 SCRATCH_DEV=/dev/pmem1 SCRATCH_MNT=/mnt/ram1 TEST_FS_MOUNT_OPTS="-o dax" EXT_MOUNT_OPTIONS="-o dax" MKFS_OPTIONS="-b4096" xfstest passed list: Ext4: 001,003,005,021,022,023,025,026,030,031,032,036,037,038,042,043,044,271,306 Generic: 1,2,3,4,5,6,7,8,9,11,12,13,14,15,16,20,21,22,23,24,25,28,29,30,31,32,33,35,37, 50,52,53,58,60,61,62,63,64,67,69,70,71,75,76,78,79,80,82,84,86,87,88,91,92,94, 96,97,98,99,103,105,112,113,114,117,120,124,126,129,130,131,135,141,169,184, 198,207,210,211,212,213,214,215,221,223,225,228,236,237,240,244,245,246,247, 248,249,255,257,258,263,277,286,294,306,307,308,309,313,315,316,318,319,337, 346,360,361,371,375,377,379,380,383,384,385,386,389,391,392,393,394,400,401, 403,404,406,409,410,411,412,413,417,420,422,423,424,425,426,427,428 v6: - These patch series was rebased on amd-staging-drm-next, which in turn is based on v5.13: https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-staging-drm-next - Handle null pointers in dmirror_allocate_chunk at test_hmm.c - Here's a link to the repo including these patch series: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/tree/alexsierrag/de… - CONFIGS required to run hmm-tests and xfstest with no special Hardware. For hmm-tests: CONFIG_EFI_FAKE_MEMMAP=y CONFIG_EFI_SOFT_RESERVE=y CONFIG_TEST_HMM=m CONFIG_RUNTIME_TESTING_MENU=y For xfstest using emulated persistant memory: CONFIG_X86_PMEM_LEGACY=y CONFIG_LIBNVDIMM=y CONFIG_BLK_DEV_PMEM=y CONFIG_FS_DAX=y CONFIG_DAX_DRIVER=y CONFIG_VIRTIO_FS=y HMM configs for both hmm-test and xfstest: CONFIG_ZONE_DEVICE=y CONFIG_HMM_MIRROR=y CONFIG_MMU_NOTIFIER=y CONFIG_DEVICE_PRIVATE=y - Kernel parameters to run hmm-tests and xfstests. These tests require to either emulate persistent memory (EPM) for xfstests or fake special memory purpose (FSPM) for hmm-tests device generic type configuration. This is achieved by using system memory for both purposes. The idea is to reserve ranges of physical address by passing specific kernel parameters. Make sure your kernel has built with the proper CONFIGS mentioned above. Once you reserve memory ranges through these two mechanisms, they cannot be used by the kernel as regular system memory. Until these kernel parameters are removed. Both mechanisms use similar parameters to define physical address and size. FSPM, however, uses a third field which is the attribute value. Here’s the syntax for both: FSPM: efi_fake_mem= nn[KMG]@ss[KMG]:aa EPM: memmap=nn[KMG]!ss[KMG] 'nn' defines the size (in GB) of memory reserved 'mm' physical/usable start address. This can be taken from BIOS-e820 mem table 'aa' specify attribute. SPM attribute is EFI_MEMORY_SP(0x40000) [KMG]: refers to kilo, mega, giga To find an available memory region address, you could look into BIOS-e820 mem table. Usually this is printed at kernel boot (dmesg). At this table, make sure you choose ranges marked as 'usable' and has at least the same or more range size as your desired reservation. Ex. Range below has a size of 13GB, from a total of 16GB of system memory. [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000044eafffff] usable In our testing, we require two ranges of 4GB each for xfstests. And two more of 1GB each for hmm-tests. Total of 10GB. Based on range above we set these two kernel parameters as follows: EPM: memmap=4G!4G memmap=4G!9G FSPM: efi_fake_mem=1G@0x200000000:0x40000,1G@0x340000000:0x40000 We alternate one EPM reserve (4GB) and one FSPM (1GB). Starting @4GB address. These kernel parameters can be passed by editing grub file. Under "/etc/default/grub". GRUB_CMDLINE_LINUX="memmap=4G!4G memmap=4G!9G efi_fake_mem=1G@0x200000000:0x40000,1G@0x340000000:0x40000" Once you have modified this file, don’t forget to update the grub. $sudo update-grub After booting with these parameters applied, you should see the new ranges defined at the "extended physical RAM map" table. This is printed at boot: reserve setup_data: [mem 0x0000000100000000-0x00000001ffffffff] persistent (type 12) reserve setup_data: [mem 0x0000000200000000-0x000000023fffffff] soft reserved reserve setup_data: [mem 0x0000000240000000-0x000000033fffffff] persistent (type 12) reserve setup_data: [mem 0x0000000340000000-0x000000037fffffff] soft reserved As you see, EPM ranges are now labeled as Persistent (type 12) and FSPM ranges as soft reserved. - Setting and running hmm-tests These tests can now be run either with device private or device generic types. This last, by setting Special Purpose Memory. To manually run them, on your kernel directory go to: $cd tools/testing/selftests/vm/ To run device private, enter: $sudo ./test_hmm.sh smoke To run device generic, you must pass the physical start addresses for both SP regions. In this example, these can be taken from above’s table labeled with "soft reserved": $sudo ./test_hmm.sh smoke 0x200000000 0x340000000 The same hmm-tests are executed for both device types. - Setting and running xfstest Clone xfstests-dev repo $git clone git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git $cd xfstests-dev $make $sudo make install On xfstests-dev directory, create a local.config file with the following information: TEST_DEV=/dev/pmem0 TEST_DIR=/mnt/ram0 SCRATCH_DEV=/dev/pmem1 SCRATCH_MNT=/mnt/ram1 TEST_FS_MOUNT_OPTS="-o dax" EXT_MOUNT_OPTIONS="-o dax" MKFS_OPTIONS="-b4096" Create mounting directories: $sudo mkdir /mnt/ram0 $sudo mkdir /mnt/ram1 Everytime you boot, you need to create ext4 file system for the emulated persistent memory partitions. $sudo mkfs.ext4 /dev/pmem0 $sudo mkfs.ext4 /dev/pmem1 To run the tests: $sudo ./check -g quick Alex Sierra (11): kernel: resource: lookup_resource as exported symbol drm/amdkfd: add SPM support for SVM drm/amdkfd: generic type as sys mem on migration to ram include/linux/mm.h: helpers to check zone device generic type mm: add generic type support to migrate_vma helpers mm: call pgmap->ops->page_free for DEVICE_GENERIC pages lib: test_hmm add ioctl to get zone device type lib: test_hmm add module param for zone device type lib: add support for device generic type in test_hmm tools: update hmm-test to support device generic type tools: update test_hmm script to support SP config Ralph Campbell (2): ext4/xfs: add page refcount helper mm: remove extra ZONE_DEVICE struct page refcount arch/powerpc/kvm/book3s_hv_uvmem.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 22 ++- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- fs/dax.c | 8 +- fs/ext4/inode.c | 5 +- fs/fuse/dax.c | 4 +- fs/xfs/xfs_file.c | 4 +- include/linux/dax.h | 10 + include/linux/memremap.h | 7 +- include/linux/mm.h | 21 +- kernel/resource.c | 1 + lib/test_hmm.c | 237 +++++++++++++++-------- lib/test_hmm_uapi.h | 16 ++ mm/internal.h | 8 + mm/memremap.c | 69 ++----- mm/migrate.c | 23 ++- mm/page_alloc.c | 3 + mm/swap.c | 45 +---- tools/testing/selftests/vm/hmm-tests.c | 142 ++++++++++++-- tools/testing/selftests/vm/test_hmm.sh | 20 +- 20 files changed, 411 insertions(+), 238 deletions(-) -- 2.32.0

5 19

← Newer
1
...
38
39
40
41
42
43
44
...
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021