- 03 Jun, 2022 1 commit
-
-
https://gitlab.freedesktop.org/abhinavk/msmDave Airlie authored
5.19 fixes for msm-next - Fix to add minimum ICC vote in the msm_mdss pm_resume path to address bootup splats - Fix to avoid dereferencing without checking in WB encoder - Fix to avoid crash during suspend in DP driver by ensuring interrupt mask bits are updated - Remove unused code from dpu_encoder_virt_atomic_check() - Fix to remove redundant init of dsc variable Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Abhinav Kumar <quic_abhinavk@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/927b201e-a734-a29d-b9fb-b9889e1f7795@quicinc.com
-
- 01 Jun, 2022 7 commits
-
-
Douglas Anderson authored
In commit a670ff57 ("drm/msm/dpu: always use mdp device to scale bandwidth") we fully moved interconnect stuff to the DPU driver. This had no change for sc7180 but _did_ have an impact for other SoCs. It made them match the sc7180 scheme. Unfortunately, the sc7180 scheme seems like it was a bit broken. Specifically the interconnect needs to be on for more than just the DPU driver's AXI bus. In the very least it also needs to be on for the DSI driver's AXI bus. This can be seen fairly easily by doing this on a ChromeOS sc7180-trogdor class device: set_power_policy --ac_screen_dim_delay=5 --ac_screen_off_delay=10 sleep 10 cd /sys/bus/platform/devices/ae94000.dsi/power echo on > control When you do that, you'll get a warning splat in the logs about "gcc_disp_hf_axi_clk status stuck at 'off'". One could argue that perhaps what I have done above is "illegal" and that it can't happen naturally in the system because in normal system usage the DPU is pretty much always on when DSI is on. That being said: * In official ChromeOS builds (admittedly a 5.4 kernel with backports) we have seen that splat at bootup. * Even though we don't use "autosuspend" for these components, we don't use the "put_sync" variants. Thus plausibly the DSI could stay "runtime enabled" past when the DPU is enabled. Techncially we shouldn't do that if the DPU's suspend ends up yanking our clock. Let's change things such that the "bare minimum" request for the interconnect happens in the mdss driver again. That means that all of the children can assume that the interconnect is on at the minimum bandwidth. We'll then let the DPU request the higher amount that it wants. It should be noted that this isn't as hacky of a solution as it might initially appear. Specifically: * Since MDSS and DPU individually get their own references to the interconnect then the framework will actually handle aggregating them. The two drivers are _not_ clobbering each other. * When the Qualcomm interconnect driver aggregates it takes the max of all the peaks. Thus having MDSS request a peak, as we're doing here, won't actually change the total interconnect bandwidth (it won't be added to the request for the DPU). This perhaps explains why the "average" requested in MDSS was historically 0 since that one _would_ be added in. NOTE also that in the downstream ChromeOS 5.4 and 5.15 kernels, we're also seeing some RPMH hangs that are addressed by this fix. These hangs are showing up in the field and on _some_ devices with enough stress testing of suspend/resume. Specifically right at suspend time with a stack crawl that looks like this (from chromeos-5.15 tree): rpmh_write_batch+0x19c/0x240 qcom_icc_bcm_voter_commit+0x210/0x420 qcom_icc_set+0x28/0x38 apply_constraints+0x70/0xa4 icc_set_bw+0x150/0x24c dpu_runtime_resume+0x50/0x1c4 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x12c/0x20c __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x370/0x4a0 __pm_runtime_resume+0x80/0xb0 dpu_kms_enable_commit+0x24/0x30 msm_atomic_commit_tail+0x12c/0x630 commit_tail+0xac/0x150 drm_atomic_helper_commit+0x114/0x11c drm_atomic_commit+0x68/0x78 drm_atomic_helper_disable_all+0x158/0x1c8 drm_atomic_helper_suspend+0xc0/0x1c0 drm_mode_config_helper_suspend+0x2c/0x60 msm_pm_prepare+0x2c/0x40 pm_generic_prepare+0x30/0x44 genpd_prepare+0x80/0xd0 device_prepare+0x78/0x17c dpm_prepare+0xb0/0x384 dpm_suspend_start+0x34/0xc0 We don't completely understand all the mechanisms in play, but the hang seemed to come and go with random factors. It's not terribly surprising that the hang is gone after this patch since the line of code that was failing is no longer present in the kernel. Fixes: a670ff57 ("drm/msm/dpu: always use mdp device to scale bandwidth") Fixes: c33b7c03 ("drm/msm/dpu: add support for clk and bw scaling for display") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # RB3 (sdm845) and Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/487884/ Link: https://lore.kernel.org/r/20220531160059.v2.1.Ie7f6d4bf8cce28131da31a43354727e417cae98d@changeidSigned-off-by:
-
Haowen Bai authored
The phys_enc->wb_idx is dereferencing before null checking, so move it after checking. Signed-off-by:
Haowen Bai <baihaowen@meizu.com> Reviewed-by:
-
Jiapeng Chong authored
Eliminate the follow clang warning: drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:544:33: warning: variable ‘mode’ set but not used [-Wunused-but-set-variable]. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Fixes: 3177589c("drm/msm/dpu: encoder: drop unused mode_fixup callback") Reviewed-by:
-
Vinod Koul authored
Commit 58dca981 ("drm/msm/disp/dpu1: Add support for DSC in encoder") added dsc_common_mode variable which was set to zero but then again programmed, so drop the superfluous init. Fixes: 58dca981 ("drm/msm/disp/dpu1: Add support for DSC in encoder") Reported-by:
kernel test robot <yujie.liu@intel.com> Reviewed-by:
Vinod Koul <vkoul@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/487208/ Link: https://lore.kernel.org/r/20220525073912.2706505-1-vkoul@kernel.orgSigned-off-by:
-
Kuogee Hsieh authored
dp_catalog_ctrl_reset() will software reset DP controller. But it will not reset programmable registers to default value. DP driver still have to clear mask bits to interrupt status registers to disable interrupts after software reset of controller. At current implementation, dp_ctrl_reset_irq_ctrl() will software reset dp controller but did not call dp_catalog_ctrl_enable_irq(false) to clear hpd related interrupt mask bits to disable hpd related interrupts due to it mistakenly think hpd related interrupt mask bits will be cleared by software reset of dp controller automatically. This mistake may cause system to crash during suspending procedure due to unexpected irq fired and trigger event thread to access dp controller registers with controller clocks are disabled. This patch fixes system crash during suspending problem by removing "enable" flag condition checking at dp_ctrl_reset_irq_ctrl() so that hpd related interrupt mask bits are cleared to prevent unexpected from happening. Changes in v2: -- add more details commit text Changes in v3: -- add synchrons_irq() -- add atomic_t suspended Changes in v4: -- correct Fixes's commit ID -- remove synchrons_irq() Changes in v5: -- revise commit text Changes in v6: -- add event_lock to protect "suspended" Changes in v7: -- delete "suspended" flag Fixes: 989ebe7b ("drm/msm/dp: do not initialize phy until plugin interrupt received") Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.19-2022-05-26-2' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.19-2022-05-26-2: amdgpu: - Update fdinfo to the common drm format UAPI: - Add VM_NOALLOC GPUVM attribute to prevent buffers for going into the MALL Add AMDGPU_GEM_CREATE_DISCARDABLE flag to create buffers that can be discarded on eviction Mesa code which uses these: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16466Signed-off-by:
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.19-2022-05-26' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.19-2022-05-26: amdgpu: - Link training fixes - DPIA fixes - Misc code cleanups - Aux fixes - Hotplug fixes - More FP clean up - Misc GFX9/10 fixes - Fix a possible memory leak in SMU shutdown - SMU 13 updates - RAS fixes - TMZ fixes - GC 11 updates - SMU 11 metrics fixes - Fix coverage blend mode for overlay plane - Note DDR vs LPDDR memory - Fuzz fix for CS IOCTL - Add new PCI DID amdkfd: - Clean up hive setup - Misc fixes radeon: - Fix a possible NULL pointer dereference Signed-off-by:
-
- 26 May, 2022 32 commits
-
-
Christian König authored
This is enough to get gputop working :) v2: rebase and some addition cleanup Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by: Shashank Sharma <shashank.sharma@amd.com> (v1) Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
Convert fdinfo format to one documented in drm-usage-stats.rst. It turned out that the existing implementation was actually completely nonsense. The calculated percentages indeed represented the usage of the engine, but with varying time slices. So 10% usage for application A could mean something completely different than 10% usage for application B. Completely nuke that and just use the now standardized nanosecond interface. v2: drop the documentation change for now, nuke percentage calculation v3: only account for each hw_ip, move the time_spend to the ctx mgr. v4: move general ctx changes into separate patch, rework the fdinfo to ctx_mgr interface so that all usages are calculated at once, drop some unecessary and dangerous refcount dance. v5: add one more comment how we calculate the time spend Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Shashank Sharma <shashank.sharma@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Christian König authored
Increase the minor version number to indicate that the new flags are available. Signed-off-by:
Marek Olšák <marek.olsak@amd.com> Signed-off-by:
-
Christian König authored
Add the AMDGPU_VM_NOALLOC flag to let userspace control MALL allocation. v2: also add the flag to the allowed flags. Signed-off-by:
-
Christian König authored
Add a AMDGPU_GEM_CREATE_DISCARDABLE flag to note that the content of a BO doesn't needs to be preserved during eviction. KFD was already using a similar functionality for SVM BOs so replace the internal flag with the new UAPI. Signed-off-by:
-
Alex Deucher authored
Add a beige goby PCI ID. Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
Lijo Lazar authored
When powerplay is not enabled, return AUTO as default level. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Acked-by:
-
Julia Lawall authored
Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
Julia Lawall authored
Spelling mistakes (triple letters) in comments. Detected with the help of Coccinelle. Signed-off-by:
-
Dave Airlie authored
Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018Signed-off-by:
-
Alex Deucher authored
Some applications want to know whether the memory is LP or not. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Candice Li authored
Check shared buf instead of init flag for xgmi ta shared buf init during xgmi ta initialization. Signed-off-by:
Candice Li <candice.li@amd.com> Reviewed-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
Prike Liang authored
On the psp13 series use ta_firmware_header_v2_0 and the asd firmware was buildin ta, so needn't request asd firmware separately. Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Reviewed-by:
Yifan Zhang <yifan1.zhang@amd.com> Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Alex Deucher authored
Validate the VCN and SDMA instances against the driver structure sizes to make sure we don't get into a situation where the firmware reports more instances than the driver supports. Reviewed-by:
-
Sung Joon Kim authored
According to the KMS man page, there is a "Coverage" alpha blend mode that assumes the pixel color values have NOT been pre-multiplied and will be done when the actual blending to the background color values happens. Previously, this mode hasn't been enabled in our driver and it was assumed that all normal overlay planes are pre-multiplied by default. When a 3rd party app is used to input a image in a specific format, e.g. PNG, as a source of a overlay plane to blend with the background primary plane, the pixel color values are not pre-multiplied. So by adding "Coverage" blend mode, our driver will support those cases. Issue fixed: Overlay plane alpha channel blending is incorrect Issue tracker: https://gitlab.freedesktop.org/drm/amd/-/issues/1769 Reference: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties Adding Coverage support also enables IGT kms_plane_alpha_blend Coverage subtests: 1. coverage-7efc 2. coverage-vs-premult-vs-constant Changes 1. Add DRM_MODE_BLEND_COVERAGE blend mode capability 2. Add "pre_multiplied_alpha" flag for Coverage case 3. Read the correct flag and set the DCN MPCC pre_multiplied register bit (only on overlay plane) Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1769Signed-off-by:
Sung Joon Kim <Sungjoon.Kim@amd.com> Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Dan Carpenter authored
The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds access. Fixes: e27c41d5 ("drm/amd/display: Support for DMUB HPD interrupt handling") Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Evan Quan authored
Suppress two compile warnings about "no previous prototype". Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Evan Quan authored
Correct the metrics version used for SMU 11.0.11/12/13. Fixes misreported GPU metrics (e.g., fan speed, etc.) depending on which version of SMU firmware is loaded. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1925Signed-off-by:
-
Jay Cornwall authored
Based on gfx10 with following changes: - GPR_ALLOC.VGPR_SIZE field moved (and size corrected in gfx10) - s_sendmsg_rtn_b64 replaces some s_sendmsg/s_getreg - Buffer instructions no longer have direct-to-LDS modifier Signed-off-by:
Jay Cornwall <jay.cornwall@amd.com> Reviewed-by:
Laurent Morichetti <laurent.morichetti@amd.com> Signed-off-by:
Eric Huang <jinhuieric.huang@amd.com> Acked-by:
-
Eric Huang authored
Most of changes are for debugger feature, and it is to simplify trap handler support for new asics in the future. Signed-off-by:
-
Alan Liu authored
Define HDMI_ACP_SEND register shift/mask. Signed-off-by:
Alan Liu <HaoPing.Liu@amd.com> Reviewed-by:
-
Lijo Lazar authored
On aldebaran, when thermal throttling happens due to excessive GPU temperature, the reason for throttling event is missed in warning message. This patch fixes it. Signed-off-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
-
Sunil Khatri authored
Add support of IP GC 10.3.7 in amdgpu_gmc_tmz_set. Signed-off-by:
Sunil Khatri <sunil.khatri@amd.com> Reviewed-by:
-
Sunil Khatri authored
Use IP version rather then code name of IPs for tmz set. Signed-off-by:
-
Sunil Khatri authored
To enable TMZ feature based on IP version needs adev->ip_version populated but its empty. Move amdgpu_gmc_tmz_set to a place where ip_version is populated. Signed-off-by:
-
Stanley.Yang authored
support umc/gfx/sdma ras on guest side Changed from V1: move sriov judgment in amdgpu_ras_interrupt_fatal_error_handler Signed-off-by:Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
Dan Carpenter authored
There is no need to check if "clock_ranges' is non-NULL. It is checked already on the line before. Signed-off-by:
-
Evan Quan authored
With the latest vbios, the memory temp reading is working. Signed-off-by:
-
Evan Quan authored
Enable OOB Monitor and SOC CG which are ready since 78.38.0. Signed-off-by:
-
Evan Quan authored
To better match with the pptable_id settings from VBIOS. Signed-off-by:
-
Evan Quan authored
To align with 78.37.0 and later PMFWs. Signed-off-by:
-
Evan Quan authored
Since PMFW will handle this properly. Driver involvement is unnecessary. Signed-off-by:
-
