- 11 Aug, 2022 3 commits
-
-
Douglas Anderson authored
1 regulator is listed but the number 2 is specified. This presumably means we try to get a regulator with no name. Fix it. Fixes: 462f7017 ("drm/msm/dsi: Fix DSI and DSI PHY regulator config from SDM660") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/496323/ Link: https://lore.kernel.org/r/20220804073608.v4.2.I94b3c3e412b7c208061349f05659e126483171b1@changeidSigned-off-by:
-
Douglas Anderson authored
3 regulators are listed but the number 2 is specified. Fix it. Fixes: 3a3ff88a ("drm/msm/dsi: Add 8x96 info in dsi_cfg") Signed-off-by:
-
Kuogee Hsieh authored
Data Symbols scrambled is required for tps4 at link training 2. Therefore SCRAMBLING_DISABLE bit should not be set for tps4 to work. RECOVERED_CLOCK_OUT_EN is for enable simple EYE test for jitter measurement with minimal equipment for embedded applications purpose and is not required to be set during normal operation. Current implementation always have RECOVERED_CLOCK_OUT_EN bit set which cause SCRAMBLING_DISABLE bit wrongly set at tps4 which prevent tps4 from working. This patch delete setting RECOVERED_CLOCK_OUT_EN to fix SCRAMBLING_DISABLE be wrongly set at tps4. Changes in v2: -- fix Fixes tag Changes in v3: -- revise commit text Changes in v4: -- fix commit text newline Changes in v5: -- fix commit text line over 75 chars Fixes: c943b494 ("drm/msm/dp: add displayPort driver support") Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
- 21 Jul, 2022 1 commit
-
-
Abhinav Kumar authored
dpu_encoder_helper_phys_cleanup() was not populating neither wb or intf to the intf_cfg before calling the reset_intf_cfg(). This causes the reset of the active bits of wb/intf to be skipped which is incorrect. Fix this by populating the relevant wb or intf indices correctly. Fixes: ae4d721c ("drm/msm/dpu: add an API to reset the encoder related hw blocks") Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # Trogdor (SC8170) Patchwork: https://patchwork.freedesktop.org/patch/494298/ Link: https://lore.kernel.org/r/1657912468-17254-1-git-send-email-quic_abhinavk@quicinc.com
-
- 20 Jul, 2022 2 commits
-
-
sunliming authored
Fix the inconsistent indenting in function msm_dsi_dphy_timing_calc_v3(). Fix the following smatch warnings: drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:350 msm_dsi_dphy_timing_calc_v3() warn: inconsistent indenting Fixes: f1fa7ff4 ("drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
sunliming <sunliming@kylinos.cn> Reviewed-by:
-
Kuogee Hsieh authored
Some userspace presumes that the first connected connector is the main display, where it's supposed to display e.g. the login screen. For laptops, this should be the main panel. This patch call drm_helper_move_panel_connectors_to_head() after drm_bridge_connector_init() to make sure eDP stay at head of connected connector list. This fixes unexpected corruption happen at eDP panel if eDP is not placed at head of connected connector list. Changes in v2: -- move drm_helper_move_panel_connectors_to_head() to dpu_kms_drm_obj_init() Changes in v4: -- move drm_helper_move_panel_connectors_to_head() to msm_drm_init() Signed-off-by:
-
- 08 Jul, 2022 1 commit
-
-
Rob Clark authored
Fixes `kms_cursor_crc --run-subtest cursor-offscreen`.. when the cursor moves offscreen the plane becomes non-visible, so we need to skip over it in crtc atomic test and mixer setup. Signed-off-by:
Rob Clark <robdclark@chromium.org> Fixes: 25fdd593 ("drm/msm: Add SDM845 DPU support") Reviewed-by:
-
- 07 Jul, 2022 15 commits
-
-
Rob Clark authored
We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0. Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged in CI: WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0 Fixes: d59be579 ("drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected") Signed-off-by: -
Rob Clark authored
No need for it to be visible outside of this one src file. Signed-off-by:
-
Rob Clark authored
I'm not entirely sure why we were using VM_MIXEDMAP. These are never CoW mappings. Let's switch to be more consistent with what other drivers and the GEM shmem helpers do. Signed-off-by:
-
Rob Clark authored
Handle the demotion to MSM_BO_WC at the userspace ABI level, and fix the remaining internal MSM_BO_UNCACHED user. Signed-off-by:
-
Rob Clark authored
To avoid preventing the display from coming up before the rootfs is mounted, without resorting to packing fw in the initrd, the GPU has this limbo state where the device is probed, but we aren't ready to start sending commands to it. This is particularly problematic for a6xx, since the GMU (which requires fw to be loaded) is the one that is controlling the power/clk/icc votes. So defer enabling runpm until we are ready to call gpu->hw_init(), as that is a point where we know we have all the needed fw and are ready to start sending commands to the coproc's. Signed-off-by:
-
Rob Clark authored
The only reason we grabbed the lock was to satisfy a bunch of places that WARN_ON() if called without the lock held. But this angers lockdep which doesn't realize no one else can be holding the lock by the time we end up destroying the object (and sees what would otherwise be a locking inversion between reservation_ww_class_mutex and fs_reclaim). Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/14Signed-off-by:
-
Dmitry Baryshkov authored
Remove unused dp_display_en/disable prototypes. While we are at it, remove extra 'data' argument that is unused. Signed-off-by:
-
Dmitry Baryshkov authored
To follow up recent changes, rename (and change type of) second dp_display_enable()'s argument from generic u32 data to bool force_link_train, which is later passed to dp_ctrl_on_stream(). Signed-off-by:
-
Dmitry Baryshkov authored
Refactoring DP code transformed several functions into empty stubs. Remove them. Reviewed-by:
-
Geert Uytterhoeven authored
With sparse ("make C=2"), lots of error: return expression in void function messages are seen. Fix this by removing the return statements to propagate void return values. Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Patchwork: https://patchwork.freedesktop.org/patch/492529/ Link: https://lore.kernel.org/r/0083bc7e23753c19902580b902582ae499b44dbf.1657113388.git.geert@linux-m68k.orgSigned-off-by:
-
Rob Clark authored
When trying to understand an iova fault devcore, once you figure out which buffer we accessed beyond the end of, it is useful to see the buffer's debug label. Signed-off-by:
-
Rob Clark authored
It is useful to know what buffers userspace thinks are associated with the submit, even if we don't care to capture their content. This brings things more inline with $debugfs/rd cmdstream dumping. Signed-off-by:
-
Dmitry Baryshkov authored
Change msm_kms_init_aspace() to use generic function device_iommu_mapped() instead of the fwnode-specific interface dev_iommu_fwspec_get(). While we are at it, stop referencing platform_bus_type directly and use the bus of the IOMMU device. Suggested-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
-
Dmitry Baryshkov authored
MDP5 and DPU drivers have the same piece of code now to initialize IOMMU and GEM address space. Move it to the msm_drv.c Signed-off-by:
-
Dmitry Baryshkov authored
Even if some IOMMU has registered itself on the platform "bus", that doesn't necessarily mean it provides translation for the device we care about. Replace iommu_present() with a more appropriate check. On Qualcomm platforms the IOMMU can be specified either for the MDP/DPU device or for its parent MDSS device depending on the actual platform. Check both of them, since that is how both DPU and MDP5 drivers work. Co-developed-by:
-
- 06 Jul, 2022 13 commits
-
-
Dmitry Baryshkov authored
Move iommu_domain_alloc() in front of adress space/IOMMU initialization. This allows us to drop final bits of struct mdp5_cfg_platform which remained from the pre-DT days. Reviewed-by:
-
Dmitry Baryshkov authored
Follow the lead of MDP5 driver and check both DPU and MDSS devices for the IOMMU specifiers. Historically DPU devices had IOMMU specified in the MDSS device tree node, but as some of MDP5 devices are being converted to the supported by the DPU driver, the driver should adapt and check both devices. Reviewed-by:
-
Rob Clark authored
In debugging fence rollover, I noticed that GPU state capture and devcore dumps were showing me negative fence numbers. Let's fix that and some related signed vs unsigned confusion. Signed-off-by:
-
Dmitry Baryshkov authored
There is little point in having a separate header just for a single opaque struct definition. Drop it now and move the struct to the dpu_hw_util.h header. Signed-off-by:
-
Dmitry Baryshkov authored
There is little point in keeping a separate MDP address and block offset in this struct. Merge them to form a new blk_addr field used for all register access. Signed-off-by:
-
Dmitry Baryshkov authored
We (nearly) do not use the length field from struct dpu_hw_blk_reg_map, so we can drop it safely. Signed-off-by:
-
Dmitry Baryshkov authored
Drop the unused field xin_id. Signed-off-by:
-
Rob Clark authored
The restriction to 4G was strictly to work around 64b math bug in some versions of SQE firmware. This appears to be fixed in a650+ SQE fw, so allow a larger address space size on these devices. Also, add a modparam override for debugging and igt. v2: Send the right version of the patch (ie. the one that actually compiles) Signed-off-by:Chia-I Wu <olvaffe@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/487601/ Link: https://lore.kernel.org/r/20220529180428.2577832-1-robdclark@gmail.com
-
Konrad Dybcio authored
Leading spaces are not something checkpatch likes, and it says so when they are present. Use tabs consistently to indent function body and unwrap a 83-char-long line, as 100 is cool nowadays. Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/487592/ Link: https://lore.kernel.org/r/20220528160353.157870-4-konrad.dybcio@somainline.orgSigned-off-by:
-
Konrad Dybcio authored
There are various SKUs of A619, ranging from 565 MHz to 850 MHz, depending on the bin. Add support for distinguishing them, so that proper frequency ranges can be applied, depending on the HW. Signed-off-by:
-
Konrad Dybcio authored
Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350), 480 (SM4350) and 750G (SM7225). Signed-off-by:
-
Konrad Dybcio authored
This BUG_ON will never be reached, and there is a comment 20 above explaining why. Signed-off-by:
-
Douglas Anderson authored
From testing on sc7180-trogdor devices, reading the GMU registers needs the GMU clocks to be enabled. Those clocks get turned on in a6xx_gmu_resume(). Confusingly enough, that function is called as a result of the runtime_pm of the GPU "struct device", not the GMU "struct device". Unfortunately the current a6xx_gpu_busy() grabs a reference to the GMU's "struct device". The fact that we were grabbing the wrong reference was easily seen to cause crashes that happen if we change the GPU's pm_runtime usage to not use autosuspend. It's also believed to cause some long tail GPU crashes even with autosuspend. We could look at changing it so that we do pm_runtime_get_if_in_use() on the GPU's "struct device", but then we run into a different problem. pm_runtime_get_if_in_use() will return 0 for the GPU's "struct device" the whole time when we're in the "autosuspend delay". That is, when we drop the last reference to the GPU but we're waiting a period before actually suspending then we'll think the GPU is off. One reason that's bad is that if the GPU didn't actually turn off then the cycle counter doesn't lose state and that throws off all of our calculations. Let's change the code to keep track of the suspend state of devfreq. msm_devfreq_suspend() is always called before we actually suspend the GPU and msm_devfreq_resume() after we resume it. This means we can use the suspended state to know if we're powered or not. NOTE: one might wonder when exactly our status function is called when devfreq is supposed to be disabled. The stack crawl I captured was: msm_devfreq_get_dev_status devfreq_simple_ondemand_func devfreq_update_target qos_notifier_call qos_max_notifier_call blocking_notifier_call_chain pm_qos_update_target freq_qos_apply apply_constraint __dev_pm_qos_update_request dev_pm_qos_update_request msm_devfreq_idle_work Fixes: eadf7928 ("drm/msm: Check for powered down HW in the devfreq callbacks") Signed-off-by:
Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/489124/ Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeidSigned-off-by:
-
- 05 Jul, 2022 5 commits
-
-
Dmitry Baryshkov authored
Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu', 'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi', 'msm-next-lumag-mdp5' and 'msm-next-lumag-mdp4' into msm-next-lumag Changes in this merge: Core: - client utilization via fdinfo support - fix fence rollover issue DPU: - constification of HW catalog - support for using encoder as CRC source - WB support on sc7180 - WB resolution fixes - enable DSPP support for sc7280 DP: - dropped custom bulk clock implementation - made dp_bridge_mode_valid() return MODE_CLOCK_HIGH where applicable - fix link retraining on resolution change MDP5: - MSM8953 perf data HDMI: - YAML'ification of schema - dropped obsolete GPIO support - misc cleanups Signed-off-by: -
Rob Clark authored
And while we are at it, let's start the fence counter close to the rollover point so that if issues slip in, they are more obvious. Signed-off-by:
-
Wan Jiabing authored
Fix following coccicheck warning: drivers/gpu/drm/msm/msm_gpu_devfreq.c:72:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_ul instead. Use div64_ul instead of do_div to avoid a possible truncation. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Patchwork: https://patchwork.freedesktop.org/patch/483499/ Link: https://lore.kernel.org/r/20220426132126.686447-1-wanjiabing@vivo.comSigned-off-by:
-
Rob Clark authored
Similar to AMD commit 87444254 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for msm. Example output: # cat /proc/`pgrep glmark2`/fdinfo/6 pos: 0 flags: 02400002 mnt_id: 21 ino: 162 drm-driver: msm drm-client-id: 7 drm-engine-gpu: 1734371319 ns drm-cycles-gpu: 1153645024 drm-maxfreq-gpu: 800000000 Hz See also: https://patchwork.freedesktop.org/patch/468505/ v2: Add dev-maxfreq-$engine and update drm-usage-stats.rst v3: spelling and compiler warning Signed-off-by:
-
Rob Clark authored
The DEFINE_DRM_GEM_FOPS() helper is a bit limiting if a driver wants to provide additional file ops, like show_fdinfo(). v2: Split out DRM_GEM_FOPS instead of making DEFINE_DRM_GEM_FOPS varardic v3: nits Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Patchwork: https://patchwork.freedesktop.org/patch/488904/ Link: https://lore.kernel.org/r/20220609174213.2265938-1-robdclark@gmail.comSigned-off-by:
-
