dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[PATCH v4 1/2] arm64: dts: qcom: sc7280: Add gpu support
by Akhil P Oommen 11 Aug '21

11 Aug '21

Add the necessary dt nodes for gpu support in sc7280. Signed-off-by: Akhil P Oommen <akhilpo(a)codeaurora.org> --- Changes in v4: - Removed the dependency on gpucc bindings (Stephen) - Reordered GPU's opp table Changes in v3: - Re-ordered the nodes based on address (Stephen) - Added the patch for gpu cooling to the stack. Changes in v2: - formatting update and removed a duplicate header (Stephen) arch/arm64/boot/dts/qcom/sc7280.dtsi | 115 +++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index 029723a..b9006d8 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -592,6 +592,85 @@ qcom,bcm-voters = <&apps_bcm_voter>; }; + gpu@3d00000 { + compatible = "qcom,adreno-635.0", "qcom,adreno"; + #stream-id-cells = <16>; + reg = <0 0x03d00000 0 0x40000>, + <0 0x03d9e000 0 0x1000>, + <0 0x03d61000 0 0x800>; + reg-names = "kgsl_3d0_reg_memory", + "cx_mem", + "cx_dbgc"; + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&adreno_smmu 0 0x401>; + operating-points-v2 = <&gpu_opp_table>; + qcom,gmu = <&gmu>; + interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt SLAVE_EBI1 0>; + interconnect-names = "gfx-mem"; + + gpu_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-315000000 { + opp-hz = /bits/ 64 <315000000>; + opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>; + opp-peak-kBps = <1804000>; + }; + + opp-450000000 { + opp-hz = /bits/ 64 <450000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS>; + opp-peak-kBps = <4068000>; + }; + + opp-550000000 { + opp-hz = /bits/ 64 <550000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>; + opp-peak-kBps = <6832000>; + }; + }; + }; + + gmu: gmu@3d69000 { + compatible="qcom,adreno-gmu-635.0", "qcom,adreno-gmu"; + reg = <0 0x03d6a000 0 0x34000>, + <0 0x3de0000 0 0x10000>, + <0 0x0b290000 0 0x10000>; + reg-names = "gmu", "rscc", "gmu_pdc"; + interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "hfi", "gmu"; + clocks = <&gpucc 5>, + <&gpucc 8>, + <&gcc GCC_DDRSS_GPU_AXI_CLK>, + <&gcc GCC_GPU_MEMNOC_GFX_CLK>, + <&gpucc 2>, + <&gpucc 15>, + <&gpucc 11>; + clock-names = "gmu", + "cxo", + "axi", + "memnoc", + "ahb", + "hub", + "smmu_vote"; + power-domains = <&gpucc 0>, + <&gpucc 1>; + power-domain-names = "cx", + "gx"; + iommus = <&adreno_smmu 5 0x400>; + operating-points-v2 = <&gmu_opp_table>; + + gmu_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>; + }; + }; + }; + gpucc: clock-controller@3d90000 { compatible = "qcom,sc7280-gpucc"; reg = <0 0x03d90000 0 0x9000>; @@ -606,6 +685,42 @@ #power-domain-cells = <1>; }; + adreno_smmu: iommu@3da0000 { + compatible = "qcom,sc7280-smmu-500", "qcom,adreno-smmu", "arm,mmu-500"; + reg = <0 0x03da0000 0 0x20000>; + #iommu-cells = <2>; + #global-interrupts = <2>; + interrupts = <GIC_SPI 673 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 675 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>, + <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>, + <&gpucc 2>, + <&gpucc 11>, + <&gpucc 5>, + <&gpucc 15>, + <&gpucc 13>; + clock-names = "gcc_gpu_memnoc_gfx_clk", + "gcc_gpu_snoc_dvm_gfx_clk", + "gpu_cc_ahb_clk", + "gpu_cc_hlos1_vote_gpu_smmu_clk", + "gpu_cc_cx_gmu_clk", + "gpu_cc_hub_cx_int_clk", + "gpu_cc_hub_aon_clk"; + + power-domains = <&gpucc 0>; + }; + stm@6002000 { compatible = "arm,coresight-stm", "arm,primecell"; reg = <0 0x06002000 0 0x1000>, -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation.

1 1

Consistently reproduce-able warning
by Josef Bacik 11 Aug '21

11 Aug '21

Hello, I have nightly tests that run on VM's against our btrfs devel tree, and I'm getting this warning every day [15522.437976] ------------[ cut here ]------------ [15522.438356] WARNING: CPU: 0 PID: 2334448 at drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x4f9/0x5c0 [ttm] [15522.439322] Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_log_writes dm_dust dm_flakey loop nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6_tables nft_compat ip_set rfkill nf_tables nfnetlink joydev iTCO_wdt iTCO_vendor_support intel_rapl_msr virtio_balloon intel_rapl_common snd_hda_codec_generic lpc_ich snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore i2c_i801 i2c_smbus zram ip_tables xfs crct10dif_pclmul crc32_pclmul crc32c_intel qxl drm_ttm_helper ttm drm_kms_helper ghash_clmulni_intel cec serio_raw virtio_blk qemu_fw_cfg drm [15522.445295] CPU: 0 PID: 2334448 Comm: kworker/0:6 Tainted: G W 5.12.0-rc1+ #155 [15522.446187] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 [15522.447066] Workqueue: events qxl_gc_work [qxl] [15522.447546] RIP: 0010:ttm_bo_release+0x4f9/0x5c0 [ttm] [15522.448093] Code: ff 48 8b bd e8 fe ff ff b9 30 75 00 00 31 d2 be 01 00 00 00 e8 a8 98 5b c9 48 8b 45 e0 e9 fb fe ff ff 4c 89 e8 e9 f3 fe ff ff <0f> 0b c7 85 94 00 00 00 00 00 00 00 48 8b 3c 24 48 8d 75 08 31 d2 [15522.450625] RSP: 0018:ffffaaf6c14d3d80 EFLAGS: 00010202 [15522.451134] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [15522.451896] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffffc039d168 [15522.452641] RBP: ffff9a028335f648 R08: 0000000000000000 R09: 0000000000000000 [15522.453387] R10: 0000000000000000 R11: ffff9a0282367488 R12: ffff9a02920b4c00 [15522.454233] R13: ffff9a0292208d90 R14: ffff9a028335f6b0 R15: ffff9a02920b4700 [15522.454936] FS: 0000000000000000(0000) GS:ffff9a02fbc00000(0000) knlGS:0000000000000000 [15522.455938] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [15522.456508] CR2: 00007f2c2fe34000 CR3: 00000001112be001 CR4: 0000000000370ef0 [15522.456910] Call Trace: [15522.457055] qxl_bo_unref+0x31/0x50 [qxl] [15522.457293] qxl_release_free_list+0x52/0xa0 [qxl] [15522.457563] qxl_release_free+0x76/0xe0 [qxl] [15522.457821] qxl_garbage_collect+0xbd/0x170 [qxl] [15522.458086] process_one_work+0x26e/0x570 [15522.458320] worker_thread+0x55/0x3c0 [15522.458526] ? process_one_work+0x570/0x570 [15522.458776] kthread+0x137/0x150 [15522.458961] ? __kthread_bind_mask+0x60/0x60 [15522.459199] ret_from_fork+0x1f/0x30 [15522.459407] irq event stamp: 0 [15522.459580] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [15522.459935] hardirqs last disabled at (0): [] copy_process+0x8c4/0x1ca0 [15522.460385] softirqs last enabled at (0): [] copy_process+0x8c4/0x1ca0 [15522.460835] softirqs last disabled at (0): [<0000000000000000>] 0x0 [15522.461179] ---[ end trace d46763407dcdfb0a ]--- You can find the full dmesg here http://toxicpanda.com/results/josefbacik/xfstests2/btrfs_compression/08-11-… I had hit this before and just turned off drm because it was going almost constantly, but I accidentally turned it back on when messing with my config. Can you guys get this fixed, it messes with my test results as kernel warnings show up as failures. I can run whatever debug stuff you want me to run, like I said these run every night and it reproduces all the time. Thanks, Josef

1 0

[PATCH] drm/tegra: vic: Use autosuspend
by Mikko Perttunen 11 Aug '21

11 Aug '21

When going idle, it's not unlikely that more work will follow. As such, use autosuspend with a 500ms suspend delay. Signed-off-by: Mikko Perttunen <mperttunen(a)nvidia.com> --- drivers/gpu/drm/tegra/vic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c index c02010ff2b7f..0204cfbe6694 100644 --- a/drivers/gpu/drm/tegra/vic.c +++ b/drivers/gpu/drm/tegra/vic.c @@ -482,6 +482,8 @@ static int vic_probe(struct platform_device *pdev) if (err < 0) goto unregister_client; } + pm_runtime_set_autosuspend_delay(&pdev->dev, 500); + pm_runtime_use_autosuspend(&pdev->dev); return 0; -- 2.32.0

1 0

[PATCH v2 1/9] dt-bindings: phy: mediatek: tphy: support type switch by pericfg
by Chunfeng Yun 11 Aug '21

11 Aug '21

Add support type switch by pericfg register between USB3, PCIe, SATA, SGMII, this is used to replace the way through efuse or jumper. Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com> --- v2: add reviewed-by Rob --- .../devicetree/bindings/phy/mediatek,tphy.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 838852cb8527..9e6c0f43f1c6 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -201,6 +201,22 @@ patternProperties: Specify the flag to enable BC1.2 if support it type: boolean + mediatek,syscon-type: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: + A phandle to syscon used to access the register of type switch, + the field should always be 3 cells long. + items: + items: + - description: + The first cell represents a phandle to syscon + - description: + The second cell represents the register offset + - description: + The third cell represents the index of config segment + enum: [0, 1, 2, 3] + required: - reg - "#phy-cells" -- 2.25.1

1 8

missing signoff on drm-intel-gt-next pull
by Dave Airlie 11 Aug '21

11 Aug '21

dim: db47fe727e1f ("drm/i915/step: s/<platform>_revid_tbl/<platform>_revids"): committer Signed-off-by missing. I'm not sure how much pain it is to fix that up, but commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54 Author: Anusha Srivatsa <anusha.srivatsa(a)intel.com> Commit: Matt Roper <matthew.d.roper(a)intel.com> drm/i915/step: s/<platform>_revid_tbl/<platform>_revids Simplify the stepping info array name. Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa(a)intel.com> Reviewed-by: Jani Nikula <jani.nikula(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matt… It's definitely missing an S-o-b by anyone who handled the patch. Let me know if it's insanely painful to fix that. Dave.

3 4

[RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability
by Vivek Kasireddy 11 Aug '21

11 Aug '21

By separating the OUT_FENCE signalling from pageflip completion allows a Guest compositor to start a new repaint cycle with a new buffer instead of waiting for the old buffer to be free. This work is based on the idea/suggestion from Simon and Pekka. This capability can be a solution for this issue: https://gitlab.freedesktop.org/wayland/weston/-/issues/514 Corresponding Weston MR: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/668 Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Tina Zhang <tina.zhang(a)intel.com> Cc: Dongwon Kim <dongwon.kim(a)intel.com> Vivek Kasireddy (4): drm: Add a capability flag to support deferred out_fence signalling virtio-gpu uapi: Add VIRTIO_GPU_F_OUT_FENCE feature drm/virtio: Add VIRTIO_GPU_CMD_RESOURCE_OUT_FENCE cmd drm/virtio: Probe and implement VIRTIO_GPU_F_OUT_FENCE feature drivers/gpu/drm/drm_file.c | 11 +++--- drivers/gpu/drm/drm_ioctl.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++++ drivers/gpu/drm/virtio/virtgpu_fence.c | 9 +++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 10 ++++-- drivers/gpu/drm/virtio/virtgpu_plane.c | 44 +++++++++++++++++++++++- drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +++++++++ include/drm/drm_mode_config.h | 9 +++++ include/uapi/drm/drm.h | 1 + include/uapi/linux/virtio_gpu.h | 12 +++++++ 12 files changed, 117 insertions(+), 7 deletions(-) -- 2.30.2

6 37

[PATCH v3 0/6] add fixes to pass DP Link Layer compliance test cases
by Kuogee Hsieh 11 Aug '21

11 Aug '21

add fixes to pass DP Link Layer compliance test cases Kuogee Hsieh (6): drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run drm/msm/dp: reduce link rate if failed at link training 1 drm/msm/dp: reset aux controller after dp_aux_cmd_fifo_tx() failed. drm/msm/dp: replug event is converted into an unplug followed by an plug events drm/msm/dp: return correct edid checksum after corrupted edid checksum read drm/msm/dp: do not end dp link training until video is ready drivers/gpu/drm/msm/dp/dp_aux.c | 3 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 137 +++++++++++++++++++++++------------- drivers/gpu/drm/msm/dp/dp_display.c | 14 ++-- drivers/gpu/drm/msm/dp/dp_panel.c | 9 ++- 4 files changed, 102 insertions(+), 61 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 12

[Bug 213935] New: AMDGPU Renoir crash/freeze while using vaapi with some video types in some apps - drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
by bugzilla-daemon＠bugzilla.kernel.org 11 Aug '21

11 Aug '21

https://bugzilla.kernel.org/show_bug.cgi?id=213935 Bug ID: 213935 Summary: AMDGPU Renoir crash/freeze while using vaapi with some video types in some apps - drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! Product: Drivers Version: 2.5 Kernel Version: 5.13.6 Hardware: x86-64 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: plusfabi(a)gmail.com Regression: No Created attachment 298139 --> https://bugzilla.kernel.org/attachment.cgi?id=298139&action=edit dmesg Jul 31 09:50:49 helium kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! Jul 31 09:50:52 helium kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=18739, emitted seq=18742 Jul 31 09:50:52 helium kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process com.github.rafo pid 4266 thread gjs:cs0 pid 4320 Jul 31 09:50:52 helium kernel: amdgpu 0000:04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110) Jul 31 09:50:53 helium kernel: amdgpu 0000:04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110) Jul 31 09:50:53 helium kernel: [drm:amdgpu_gfx_enable_kcq.cold [amdgpu]] *ERROR* KCQ enable failed Jul 31 09:50:53 helium kernel: [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <gfx_v9_0> failed -110 In certain situations I'm able to crash/freeze my system by playing mp4 videos with (vaapi-acceleration) enabled. If the crash/freeze happens, the screen goes black and the system isn't responding to any input. Sadly in this case it's at random if something was able to write output to the log. In most cases there is nothing written about the crash in the log. My environment is GNOME in Wayland mode With native Wayland apps (in this Case Firefox and clapper (https://rafostar.github.io/clapper/) APU is an Ryzen 5 4500U For Firefox I'm not able to reliable recreate that bug. It happens at random while scrolling in twitter and reddit. Never happens in Netflix or Youtube for example. Luckily I was able to recreate it with an app called clapper and a video provided by someone on reddit: https://cdn.discordapp.com/attachments/399812928854949890/87091033954859018… Steps: 1. Have GNOME running in Wayland mode and vaapi installed (check with 'vainfo`) 2. Install clapper 3. Download the video 4. Run the video in Clapper 5. While running, launch the video again in clapper It should *not* create another instance of clapper, but try to re-launch the video in the same instance of clapper that was already running. You'll hear maybe a few sec of the audio, but your whole session is frozen and will enter an all black screen without possible recovery a few sec later. I'm able to recreate this with every Kernel I tested. So down to 5.8 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 2

[PATCH] drm/doc/rfc: drop lmem uapi section
by Daniel Vetter 11 Aug '21

11 Aug '21

We still have quite a bit more work to do with overall reworking of the ttm-based dg1 code, but the uapi stuff is now finalized with the latest pull. So remove that. This also fixes kerneldoc build warnings because we've included the same headers in two places, resulting in sphinx complaining about duplicated symbols. This regression has been created when we moved the uapi definitions to the real include/uapi/ folder in 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header") Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header") Cc: Matthew Auld <matthew.auld(a)intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- Documentation/gpu/rfc/i915_gem_lmem.rst | 107 ------------------------ 1 file changed, 107 deletions(-) diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst index 675ba8620d66..91be041e68cc 100644 --- a/Documentation/gpu/rfc/i915_gem_lmem.rst +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -22,110 +22,3 @@ real, with all the uAPI bits is: * SET/GET ioctl caching(see `I915 SET/GET CACHING`_) * Send RFC(with mesa-dev on cc) for final sign off on the uAPI * Add pciid for DG1 and turn on uAPI for real - -New object placement and region query uAPI -========================================== -Starting from DG1 we need to give userspace the ability to allocate buffers from -device local-memory. Currently the driver supports gem_create, which can place -buffers in system memory via shmem, and the usual assortment of other -interfaces, like dumb buffers and userptr. - -To support this new capability, while also providing a uAPI which will work -beyond just DG1, we propose to offer three new bits of uAPI: - -DRM_I915_QUERY_MEMORY_REGIONS ------------------------------ -New query ID which allows userspace to discover the list of supported memory -regions(like system-memory and local-memory) for a given device. We identify -each region with a class and instance pair, which should be unique. The class -here would be DEVICE or SYSTEM, and the instance would be zero, on platforms -like DG1. - -Side note: The class/instance design is borrowed from our existing engine uAPI, -where we describe every physical engine in terms of its class, and the -particular instance, since we can have more than one per class. - -In the future we also want to expose more information which can further -describe the capabilities of a region. - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions - -GEM_CREATE_EXT --------------- -New ioctl which is basically just gem_create but now allows userspace to provide -a chain of possible extensions. Note that if we don't provide any extensions and -set flags=0 then we get the exact same behaviour as gem_create. - -Side note: We also need to support PXP[1] in the near future, which is also -applicable to integrated platforms, and adds its own gem_create_ext extension, -which basically lets userspace mark a buffer as "protected". - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_create_ext - -I915_GEM_CREATE_EXT_MEMORY_REGIONS ----------------------------------- -Implemented as an extension for gem_create_ext, we would now allow userspace to -optionally provide an immutable list of preferred placements at creation time, -in priority order, for a given buffer object. For the placements we expect -them each to use the class/instance encoding, as per the output of the regions -query. Having the list in priority order will be useful in the future when -placing an object, say during eviction. - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_create_ext_memory_regions - -One fair criticism here is that this seems a little over-engineered[2]. If we -just consider DG1 then yes, a simple gem_create.flags or something is totally -all that's needed to tell the kernel to allocate the buffer in local-memory or -whatever. However looking to the future we need uAPI which can also support -upcoming Xe HP multi-tile architecture in a sane way, where there can be -multiple local-memory instances for a given device, and so using both class and -instance in our uAPI to describe regions is desirable, although specifically -for DG1 it's uninteresting, since we only have a single local-memory instance. - -Existing uAPI issues -==================== -Some potential issues we still need to resolve. - -I915 MMAP ---------- -In i915 there are multiple ways to MMAP GEM object, including mapping the same -object using different mapping types(WC vs WB), i.e multiple active mmaps per -object. TTM expects one MMAP at most for the lifetime of the object. If it -turns out that we have to backpedal here, there might be some potential -userspace fallout. - -I915 SET/GET CACHING --------------------- -In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but -DG1 doesn't support non-snooped pcie transactions, so we can just always -allocate as WB for smem-only buffers. If/when our hw gains support for -non-snooped pcie transactions then we must fix this mode at allocation time as -a new GEM extension. - -This is related to the mmap problem, because in general (meaning, when we're -not running on intel cpus) the cpu mmap must not, ever, be inconsistent with -allocation mode. - -Possible idea is to let the kernel picks the mmap mode for userspace from the -following table: - -smem-only: WB. Userspace does not need to call clflush. - -smem+lmem: We only ever allow a single mode, so simply allocate this as uncached -memory, and always give userspace a WC mapping. GPU still does snooped access -here(assuming we can't turn it off like on DG1), which is a bit inefficient. - -lmem only: always WC - -This means on discrete you only get a single mmap mode, all others must be -rejected. That's probably going to be a new default mode or something like -that. - -Links -===== -[1] https://patchwork.freedesktop.org/series/86798/ - -[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 -- 2.32.0

3 3

[PATCH v9, 0/5] drm/mediatek: add support for mediatek SOC MT8192
by Yongqiang Niu 11 Aug '21

11 Aug '21

Change since v8: rebase Linux v5.14-rc1 Yongqiang Niu (5): drm/mediatek: add component OVL_2L2 drm/mediatek: add component POSTMASK drm/mediatek: add component RDMA4 soc: mediatek: add mtk mutex support for MT8192 drm/mediatek: add support for mediatek SOC MT8192 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++ drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 20 ++++++ drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102 ++++++++++++++++++++-------- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 42 ++++++++++++ drivers/soc/mediatek/mtk-mutex.c | 35 ++++++++++ 7 files changed, 183 insertions(+), 29 deletions(-) -- 1.8.1.1.dirty

1 5

← Newer
1
...
55
56
57
58
59
60
61
...
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