- 23 Jun, 2022 3 commits
-
-
sunliming authored
Fixes the following smatch warning: drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:261 dpu_encoder_phys_wb_atomic_check() warn: variable dereferenced before check 'conn_state' Fixes: d7d0e73f ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by:
sunliming <sunliming@kylinos.cn> Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/490850/ Link: https://lore.kernel.org/r/20220623012707.453972-1-sunliming@kylinos.cnSigned-off-by:
-
Kuogee Hsieh authored
During msm initialize phase, dp_display_unbind() will be called to undo initializations had been done by dp_display_bind() previously if there is error happen at msm_drm_bind. Under this kind of circumstance, drm_device may not be populated completed which causes system crash at drm_dev_dbg(). This patch reset drm_dev to NULL so that following drm_dev_dbg() will not refer to any internal fields of drm_device to prevent system from crashing. Below are panic stack trace, [ 53.584904] Unable to handle kernel paging request at virtual address 0000000070018001 . [ 53.702212] Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT) [ 53.710445] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 53.717596] pc : string_nocheck+0x1c/0x64 [ 53.721738] lr : string+0x54/0x60 [ 53.725162] sp : ffffffc013d6b650 [ 53.728590] pmr_save: 000000e0 [ 53.731743] x29: ffffffc013d6b650 x28: 0000000000000002 x27: 0000000000ffffff [ 53.739083] x26: ffffffc013d6b710 x25: ffffffd07a066ae0 x24: ffffffd07a419f97 [ 53.746420] x23: ffffffd07a419f99 x22: ffffff81fef360d4 x21: ffffff81fef364d4 [ 53.753760] x20: ffffffc013d6b6f8 x19: ffffffd07a06683c x18: 0000000000000000 [ 53.761093] x17: 4020386678302f30 x16: 00000000000000b0 x15: ffffffd0797523c8 [ 53.768429] x14: 0000000000000004 x13: ffff0000ffffff00 x12: ffffffd07a066b2c [ 53.775780] x11: 0000000000000000 x10: 000000000000013c x9 : 0000000000000000 [ 53.783117] x8 : ffffff81fef364d4 x7 : 0000000000000000 x6 : 0000000000000000 [ 53.790445] x5 : 0000000000000000 x4 : ffff0a00ffffff04 x3 : ffff0a00ffffff04 [ 53.797783] x2 : 0000000070018001 x1 : ffffffffffffffff x0 : ffffff81fef360d4 [ 53.805136] Call trace: [ 53.807667] string_nocheck+0x1c/0x64 [ 53.811439] string+0x54/0x60 [ 53.814498] vsnprintf+0x374/0x53c [ 53.818009] pointer+0x3dc/0x40c [ 53.821340] vsnprintf+0x398/0x53c [ 53.824854] vscnprintf+0x3c/0x88 [ 53.828274] __trace_array_vprintk+0xcc/0x2d4 [ 53.832768] trace_array_printk+0x8c/0xb4 [ 53.836900] drm_trace_printf+0x74/0x9c [ 53.840875] drm_dev_dbg+0xfc/0x1b8 [ 53.844480] dp_pm_suspend+0x70/0xf8 [ 53.848164] dpm_run_callback+0x60/0x1a0 [ 53.852222] __device_suspend+0x304/0x3f4 [ 53.856363] dpm_suspend+0xf8/0x3a8 [ 53.859959] dpm_suspend_start+0x8c/0xc0 Fixes: 570d3e5d ("drm/msm/dp: stop event kernel thread when DP unbind") Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/490756/ Link: https://lore.kernel.org/r/1655927731-22396-1-git-send-email-quic_khsieh@quicinc.comSigned-off-by:
-
Stephen Boyd authored
The 'vsync_cnt' is used to count the number of frames for a crtc. Unfortunately, we increment the count after waking up userspace via dpu_crtc_vblank_callback() calling drm_crtc_handle_vblank(). drm_crtc_handle_vblank() wakes up userspace processes that have called drm_wait_vblank_ioctl(), and if that ioctl is expecting the count to increase it won't. Increment the count before calling into the drm APIs so that we don't have to worry about ordering the increment with anything else in drm. This fixes a software video decode test that fails to see frame counts increase on Trogdor boards. Cc: Mark Yacoub <markyacoub@chromium.org> Cc: Jessica Zhang <quic_jesszhan@quicinc.com> Fixes: 885455d6 ("drm/msm: Change dpu_crtc_get_vblank_counter to use vsync count.") Signed-off-by:
-
- 18 Jun, 2022 6 commits
-
-
Kuogee Hsieh authored
Display resolution change is implemented through drm modeset. Older modeset (resolution) has to be disabled first before newer modeset (resolution) can be enabled. Display disable will turn off both pixel clock and main link clock so that main link have to be re-trained during display enable to have new video stream flow again. At current implementation, display enable function manually kicks up irq_hpd_handle which will read panel link status and start link training if link status is not in sync state. However, there is rare case that a particular panel links status keep staying in sync for some period of time after main link had been shut down previously at display disabled. In this case, main link retraining will not be executed by irq_hdp_handle(). Hence video stream of newer display resolution will fail to be transmitted to panel due to main link is not in sync between host and panel. This patch will bypass irq_hpd_handle() in favor of directly call dp_ctrl_on_stream() to always perform link training in regardless of main link status. So that no unexpected exception resolution change failure cases will happen. Also this implementation are more efficient than manual kicking off irq_hpd_handle function. Changes in v2: -- set force_link_train flag on DP only (is_edp == false) Changes in v3: -- revise commit text -- add Fixes tag Changes in v4: -- revise commit text Changes in v5: -- fix spelling at commit text Changes in v6: -- split dp_ctrl_on_stream() for phy test case -- revise commit text for modeset Changes in v7: -- drop 0 assignment at local variable (ret = 0) Changes in v8: -- add patch to remove pixel_rate from dp_ctrl Changes in v9: -- forward declare dp_ctrl_on_stream_phy_test_report() Fixes: 62671d2e ("drm/msm/dp: fixes wrong connection state caused by failure of link train") Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Abhinav Kumar authored
As explained in [1], using max_linewidth to limit the modes does not seem to remove 4K modes on chipsets such as sm8250 where the max_linewidth actually supports 4k. This would have been alright if dual SSPP support was present but otherwise fails the per SSPP bandwidth check. The ideal way to implement this would be to filter out the modes which will exceed the bandwidth check by computing it. But this would be an exhaustive solution till we have dual SSPP support. Let's instead use max_mixer_width to limit the modes. max_mixer_width still remains 2560 on sm8250 so even if the max_linewidth is 4096, the only way 4k modes could have been supported is to have source split enabled on the SSPP. Since source split support is not enabled yet in DPU driver, enforce max_mixer_width as the upper limit on the modes. [1] https://patchwork.freedesktop.org/patch/489662/ Fixes: e67dcecd ("drm/msm/dpu: limit writeback modes according to max_linewidth") Signed-off-by:
-
Kuogee Hsieh authored
During msm initialize phase, dp_display_unbind() will be called to undo initializations had been done by dp_display_bind() previously if there is error happen at msm_drm_bind. In this case, core_initialized flag had to be check to make sure clocks is on before update DP controller register to disable HPD interrupts. Otherwise system will crash due to below NOC fatal error. QTISECLIB [01f01a7ad]CNOC2 ERROR: ERRLOG0_LOW = 0x00061007 QTISECLIB [01f01a7ad]GEM_NOC ERROR: ERRLOG0_LOW = 0x00001007 QTISECLIB [01f0371a0]CNOC2 ERROR: ERRLOG0_HIGH = 0x00000003 QTISECLIB [01f055297]GEM_NOC ERROR: ERRLOG0_HIGH = 0x00000003 QTISECLIB [01f072beb]CNOC2 ERROR: ERRLOG1_LOW = 0x00000024 QTISECLIB [01f0914b8]GEM_NOC ERROR: ERRLOG1_LOW = 0x00000042 QTISECLIB [01f0ae639]CNOC2 ERROR: ERRLOG1_HIGH = 0x00004002 QTISECLIB [01f0cc73f]GEM_NOC ERROR: ERRLOG1_HIGH = 0x00004002 QTISECLIB [01f0ea092]CNOC2 ERROR: ERRLOG2_LOW = 0x0009020c QTISECLIB [01f10895f]GEM_NOC ERROR: ERRLOG2_LOW = 0x0ae9020c QTISECLIB [01f125ae1]CNOC2 ERROR: ERRLOG2_HIGH = 0x00000000 QTISECLIB [01f143be7]GEM_NOC ERROR: ERRLOG2_HIGH = 0x00000000 QTISECLIB [01f16153a]CNOC2 ERROR: ERRLOG3_LOW = 0x00000000 QTISECLIB [01f17fe07]GEM_NOC ERROR: ERRLOG3_LOW = 0x00000000 QTISECLIB [01f19cf89]CNOC2 ERROR: ERRLOG3_HIGH = 0x00000000 QTISECLIB [01f1bb08e]GEM_NOC ERROR: ERRLOG3_HIGH = 0x00000000 QTISECLIB [01f1d8a31]CNOC2 ERROR: SBM1 FAULTINSTATUS0_LOW = 0x00000002 QTISECLIB [01f1f72a4]GEM_NOC ERROR: SBM0 FAULTINSTATUS0_LOW = 0x00000001 QTISECLIB [01f21a217]CNOC3 ERROR: ERRLOG0_LOW = 0x00000006 QTISECLIB [01f23dfd3]NOC error fatal changes in v2: -- drop the first patch (drm/msm: enable msm irq after all initializations are done successfully at msm_drm_init()) since the problem had been fixed by other patch Fixes: 570d3e5d ("drm/msm/dp: stop event kernel thread when DP unbind") Signed-off-by:
-
Miaoqian Lin authored
of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 86418f90 ("drm: convert drivers to use of_graph_get_remote_node") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Reviewed-by:
-
Rob Clark authored
Prior to the last commit, this could result in setting the GPU written fence value back to an older value, if we had missed updating completed_fence prior to suspend. This was mostly harmless as the GPU would eventually overwrite it again with the correct value. But we should just not do this. Instead just leave a sanity check that the fence looks plausible (in case the GPU scribbled on memory). Reported-by:
Steev Klimaszewski <steev@kali.org> Fixes: 95d1deb0 ("drm/msm/gem: Add fenced vma unpin") Signed-off-by:
-
Rob Clark authored
I noticed while looking at some traces, that we could miss calls to msm_update_fence(), as the irq could have raced with retire_submits() which could have already popped the last submit on a ring out of the queue of in-flight submits. But walking the list of submits in the irq handler isn't really needed, as dma_fence_is_signaled() will dtrt. So lets just drop it entirely. v2: use spin_lock_irqsave/restore as we are no longer protected by the spin_lock_irqsave/restore() in update_fences() Reported-by:
-
- 15 Jun, 2022 2 commits
-
-
Rob Clark authored
Keep the warn, but drop the early return. If we do manage to hit this sort of issue, skipping the cleanup just makes things worse (dangling drm_mm_nodes when the msm_gem_vma is freed, etc). Whereas the worst that happens if we tear down a mapping the GPU is accessing is that we get GPU iova faults, but otherwise the world keeps spinning. Signed-off-by:
-
Rob Clark authored
Previously the BO_PINNED state in the submit was tracking two related but different things: (1) that the buffer object was pinned, and (2) that the vma (mapping within a set of pagetables) was pinned. But with fenced vma unpin (needed so that userspace couldn't race with retire path for releasing a vma) these two were decoupled. The fact that the BO_PINNED flag was already cleared meant that we leaked the bo pin count which should have been dropped when the submit was retired. So split this state into BO_OBJ_PINNED and BO_VMA_PINNED, so they can be dropped independently. Fixes: 95d1deb0 ("drm/msm/gem: Add fenced vma unpin") Signed-off-by:
-
- 14 Jun, 2022 1 commit
-
-
Jonathan Marek authored
The dma_map_sgtable() call (used to invalidate cache) overwrites sgt->nents with 1, so msm_iommu_pagetable_map maps only the first physical segment. To fix this problem use for_each_sgtable_sg(), which uses orig_nents. Fixes: b145c6e6 ("drm/msm: Add support to create a local pagetable") Signed-off-by:
Jonathan Marek <jonathan@marek.ca> Link: https://lore.kernel.org/r/20220613221019.11399-1-jonathan@marek.caSigned-off-by:
-
- 13 Jun, 2022 1 commit
-
-
Rob Clark authored
In msm_devfreq_suspend() we cancel idle_work synchronously so that it doesn't run after we power of the hw or in the resume path. But this means that we want to ensure that idle_work is not scheduled *after* we no longer hold a runpm ref. So switch the ordering of pm_runtime_put() vs msm_devfreq_idle(). v2. Only move the runpm _put_autosuspend, and not the _mark_last_busy() Fixes: 9bc95570 ("drm/msm: Devfreq tuning") Signed-off-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220608161334.2140611-1-robdclark@gmail.comSigned-off-by:
-
- 07 Jun, 2022 1 commit
-
-
Maximilian Luz authored
Following commit 17e822f7 ("drm/msm: fix unbalanced pm_runtime_enable in adreno_gpu_{init, cleanup}"), any call to adreno_unbind() will disable runtime PM twice, as indicated by the call trees below: adreno_unbind() -> pm_runtime_force_suspend() -> pm_runtime_disable() adreno_unbind() -> gpu->funcs->destroy() [= aNxx_destroy()] -> adreno_gpu_cleanup() -> pm_runtime_disable() Note that pm_runtime_force_suspend() is called right before gpu->funcs->destroy() and both functions are called unconditionally. With recent addition of the eDP AUX bus code, this problem manifests itself when the eDP panel cannot be found yet and probing is deferred. On the first probe attempt, we disable runtime PM twice as described above. This then causes any later probe attempt to fail with [drm:adreno_load_gpu [msm]] *ERROR* Couldn't power up the GPU: -13 preventing the driver from loading. As there seem to be scenarios where the aNxx_destroy() functions are not called from adreno_unbind(), simply removing pm_runtime_disable() from inside adreno_unbind() does not seem to be the proper fix. This is what commit 17e822f7 ("drm/msm: fix unbalanced pm_runtime_enable in adreno_gpu_{init, cleanup}") intended to fix. Therefore, instead check whether runtime PM is still enabled, and only disable it in that case. Fixes: 17e822f7 ("drm/msm: fix unbalanced pm_runtime_enable in adreno_gpu_{init, cleanup}") Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Tested-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Rob Clark <robdclark@gmail.com> Link: https://lore.kernel.org/r/20220606211305.189585-1-luzmaximilian@gmail.comSigned-off-by:
-
- 02 Jun, 2022 2 commits
-
-
Rob Clark authored
If a GEM object is allocated, and then exported as a dma-buf fd which is mmap'd before or without the GEM buffer being directly mmap'd, the vma_node could be unitialized. This leads to a situation where the CPU mapping is not correctly torn down in drm_vma_node_unmap(). Fixes: e5516553 ("drm: call drm_gem_object_funcs.mmap with fake offset") Signed-off-by:
-
Rob Clark authored
Merge tag 'msm-next-5.19-fixes-06-01' of https://gitlab.freedesktop.org/abhinavk/msm into msm-fixes-staging 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:
-
- 01 Jun, 2022 5 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:
-
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:
-
- 19 May, 2022 2 commits
-
-
https://gitlab.freedesktop.org/abhinavk/msmRob Clark authored
Merge tag 'msm-next-5.19-fixes' of https://gitlab.freedesktop.org/abhinavk/msm into msm-fixes-staging 5.19 fixes for msm-next - Limiting WB modes to max sspp linewidth - Fixing the supported rotations to add 180 back for IGT - Fix to handle pm_runtime_get_sync() errors to avoid unclocked access in the bind() path for dpu driver - Fix the irq_free() without request issue which was a big-time hitter in the CI-runs. Signed-off-by:
-
Abhinav Kumar authored
If there are errors while trying to enable the pm in the bind path, it will lead to unclocked access of hw revision register thereby crashing the device. This will not address why the pm_runtime_get_sync() fails but at the very least we should be able to prevent the crash by handling the error and bailing out earlier. changes in v2: - use pm_runtime_resume_and_get() instead of pm_runtime_get_sync() Fixes: 25fdd593 ("drm/msm: Add SDM845 DPU support") Signed-off-by:
-
- 18 May, 2022 7 commits
-
-
Abhinav Kumar authored
DRM_MODE_ROTATE_180 was previously marked as supported even for devices not supporting inline rotation. This is true because the SSPPs can always flip the image. After inline rotation support changes, this bit was removed and kms_rotation_crc IGT test starts skipping now whereas it was previously passing. Restore DRM_MODE_ROTATE_180 bit to the supported rotations list. Fixes: dabfdd89 ("add inline rotation support for sc7280") Signed-off-by:
-
Dmitry Baryshkov authored
As msm_drm_uninit() is called from the msm_drm_init() error path, additional care should be necessary as not to call the free_irq() for the IRQ that was not requested before (because an error occured earlier than the request_irq() call). This fixed the issue reported with the following backtrace: [ 8.571329] Trying to free already-free IRQ 187 [ 8.571339] WARNING: CPU: 0 PID: 76 at kernel/irq/manage.c:1895 free_irq+0x1e0/0x35c [ 8.588746] Modules linked in: pmic_glink pdr_interface fastrpc qrtr_smd snd_soc_hdmi_codec msm fsa4480 gpu_sched drm_dp_aux_bus qrtr i2c_qcom_geni crct10dif_ce qcom_stats qcom_q6v5_pas drm_display_helper gpi qcom_pil_info drm_kms_helper qcom_q6v5 qcom_sysmon qcom_common qcom_glink_smem qcom_rng mdt_loader qmi_helpers phy_qcom_qmp ufs_qcom typec qnoc_sm8350 socinfo rmtfs_mem fuse drm ipv6 [ 8.624154] CPU: 0 PID: 76 Comm: kworker/u16:2 Not tainted 5.18.0-rc5-next-20220506-00033-g6cee8cab6089-dirty #419 [ 8.624161] Hardware name: Qualcomm Technologies, Inc. SM8350 HDK (DT) [ 8.641496] Workqueue: events_unbound deferred_probe_work_func [ 8.647510] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.654681] pc : free_irq+0x1e0/0x35c [ 8.658454] lr : free_irq+0x1e0/0x35c [ 8.662228] sp : ffff800008ab3950 [ 8.665642] x29: ffff800008ab3950 x28: 0000000000000000 x27: ffff16350f56a700 [ 8.672994] x26: ffff1635025df080 x25: ffff16350251badc x24: ffff16350251bb90 [ 8.680343] x23: 0000000000000000 x22: 00000000000000bb x21: ffff16350e8f9800 [ 8.687690] x20: ffff16350251ba00 x19: ffff16350cbd5880 x18: ffffffffffffffff [ 8.695039] x17: 0000000000000000 x16: ffffa2dd12179434 x15: ffffa2dd1431d02d [ 8.702391] x14: 0000000000000000 x13: ffffa2dd1431d028 x12: 662d79646165726c [ 8.709740] x11: ffffa2dd13fd2438 x10: 000000000000000a x9 : 00000000000000bb [ 8.717111] x8 : ffffa2dd13fd23f0 x7 : ffff800008ab3750 x6 : 00000000fffff202 [ 8.724487] x5 : ffff16377e870a18 x4 : 00000000fffff202 x3 : ffff735a6ae1b000 [ 8.731851] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff1635015f8000 [ 8.739217] Call trace: [ 8.741755] free_irq+0x1e0/0x35c [ 8.745198] msm_drm_uninit.isra.0+0x14c/0x294 [msm] [ 8.750548] msm_drm_bind+0x28c/0x5d0 [msm] [ 8.755081] try_to_bring_up_aggregate_device+0x164/0x1d0 [ 8.760657] __component_add+0xa0/0x170 [ 8.764626] component_add+0x14/0x20 [ 8.768337] dp_display_probe+0x2a4/0x464 [msm] [ 8.773242] platform_probe+0x68/0xe0 [ 8.777043] really_probe.part.0+0x9c/0x28c [ 8.781368] __driver_probe_device+0x98/0x144 [ 8.785871] driver_probe_device+0x40/0x140 [ 8.790191] __device_attach_driver+0xb4/0x120 [ 8.794788] bus_for_each_drv+0x78/0xd0 [ 8.798751] __device_attach+0xdc/0x184 [ 8.802713] device_initial_probe+0x14/0x20 [ 8.807031] bus_probe_device+0x9c/0xa4 [ 8.810991] deferred_probe_work_func+0x88/0xc0 [ 8.815667] process_one_work+0x1d0/0x320 [ 8.819809] worker_thread+0x14c/0x444 [ 8.823688] kthread+0x10c/0x110 [ 8.827036] ret_from_fork+0x10/0x20 Reported-by:
-
Abhinav Kumar authored
Writeback modes were being added according to mode_config.max_width but this is assigned to double of max_mixer_width. For compositors/clients using a single SSPP, this will fail the dpu_plane's atomic check as it checks for max_linewidth. Limit writeback modes according to max_linewidth to allow even compositors/clients which use only a single SSPP to use writeback. Fixes: 77b001ac ("drm/msm/dpu: add the writeback connector layer") Reported-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by:
-
Hangyu Hua authored
drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails. Fixes: e172d10a ("drm/msm/mdp5: Add hardware cursor support") Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Link: https://lore.kernel.org/r/20220509061125.18585-1-hbh25y@gmail.comSigned-off-by:
-
Rob Clark authored
The offset got dropped by accident. Fixes: d413e6f9 ("drm/msm: Drop msm_gem_iova()") Signed-off-by:
-
Miaoqian Lin authored
of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. a6xx_gmu_init() passes the node to of_find_device_by_node() and of_dma_configure(), of_find_device_by_node() will takes its reference, of_dma_configure() doesn't need the node after usage. Add missing of_node_put() to avoid refcount leak. Fixes: 4b565ca5 ("drm/msm: Add A6XX device support") Signed-off-by:
-
Douglas Anderson authored
Commit 7d8e9a90 ("drm/msm/dsi: move DSI host powerup to modeset time") caused sc7180 Chromebooks that use the parade-ps8640 bridge chip to fail to turn the display back on after it turns off. Unfortunately, it doesn't look easy to fix the parade-ps8640 driver to handle the new power sequence. The Linux driver has almost nothing in it and most of the logic for this bridge chip is in black-box firmware that the bridge chip uses. Also unfortunately, reverting the patch will break "tc358762". The long term solution here is probably Dave Stevenson's series [1] that would give more flexibility. However, that is likely not a quick fix. For the short term, we'll look at the compatible of the next bridge in the chain and go back to the old way for the Parade PS8640 bridge chip. If it's found that other bridge chips also need this workaround then we can add them to the list or consider inverting the condition. However, the hope is that the framework will not take too much longer to land and we won't have to add anything other than ps8640 here. [1] https://lore.kernel.org/r/cover.1646406653.git.dave.stevenson@raspberrypi.com Fixes: 7d8e9a90 ("drm/msm/dsi: move DSI host powerup to modeset time") Suggested-by:
-
- 07 May, 2022 3 commits
-
-
Dmitry Baryshkov authored
For the past several releases I have been assisting Rob by writing, collecting, testing and integrating patches for non-GPU and non-core parts of MSM DRM driver, while Rob is more interested in improving the GPU-related part. Let's note this in the MAINTAINERS file. While we are at it, per Rob's suggestion let's also promote Abhinav Kumar to M: (as he is actively working on the driver) and switch Sean Paul to R: (since he isn't doing much on msm these days). Signed-off-by:
-
Dmitry Baryshkov authored
There is no need to check that kfree() argument is not NULL. Remove extra check and call kfree() unconditionally. Reported-by:
-
Rob Clark authored
Running the GPU without an IOMMU is not really a supported (or sane) configuration. Yet it can be useful during SoC bringup (ie. if the iommu driver doesn't work yet). Lets limit it to users who already have /dev/mem access, to avoid the chance that a user accidentially configures kernel without IOMMU support. Signed-off-by:
-
- 06 May, 2022 7 commits
-
-
Dmitry Baryshkov authored
Remove dividers that are not recommended for DSI DPHY mode when setting up the clock tree for the DSI pixel clock. Signed-off-by:
-
Douglas Anderson authored
When rebooting on my sc7280-herobrine based device, I got a crash. Upon debugging, I found that I was in msm_drv_shutdown() and my "pdev" was the one associated with mdss_probe(). From source, I found that mdss_probe() has the line: platform_set_drvdata(pdev, mdss); ...where "mdss" is of type "struct msm_mdss *". Also from source, I saw that in msm_drv_shutdown() we have the line: struct msm_drm_private *priv = platform_get_drvdata(pdev); This is a mismatch and is the root of the problem. Further digging made it apparent that msm_drv_shutdown() is only supposed to be used for parts of the msm display framework that also call msm_drv_probe() but mdss_probe() doesn't call msm_drv_probe(). Let's remove the shutdown functon from msm_mdss.c. Digging a little further, code inspection found that two drivers that use msm_drv_probe() weren't calling msm_drv_shutdown(). Let's add it to them. Fixes: 6874f48b ("drm/msm: make mdp5/dpu devices master components") Signed-off-by:
-
Dan Carpenter authored
The msm_gem_prime_get_sg_table() needs to return error pointers on error. This is called from drm_gem_map_dma_buf() and returning a NULL will lead to a crash in that function. Fixes: ac451467 ("drm/msm: fix msm_gem_prime_get_sg_table()") Signed-off-by:
-
Jessica Zhang authored
There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Reported-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
-
Jessica Zhang authored
mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Reported-by:
-
Kuogee Hsieh authored
Event thread supposed to exit from its while loop after kthread_stop(). However there may has possibility that event thread is pending in the middle of wait_event due to condition checking never become true. To make sure event thread exit its loop after kthread_stop(), this patch OR kthread_should_stop() into wait_event's condition checking so that event thread will exit its loop after kernal_stop(). Changes in v2: -- correct spelling error at commit title Changes in v3: -- remove unnecessary parenthesis -- while(1) to replace while (!kthread_should_stop()) Reported-by:
-
Dmitry Baryshkov authored
Correct a typo in the address of the second DSI PHY in the SDM660 device config. Fixes: 694dd304 ("drm/msm/dsi: Add phy configuration for SDM630/636/660") Cc: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/484697/ Link: https://lore.kernel.org/r/20220503204340.935532-1-dmitry.baryshkov@linaro.orgSigned-off-by:
-
