- 22 May, 2023 17 commits
-
-
Marijn Suijten authored
A bunch of registers were appended at the end in e.g. commit 91143873 ("drm/msm/dpu: Add MISR register support for interface") rather than being inserted in a place that maintains numerical sorting: restore said numerical sorting. Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/534213/ Link: https://lore.kernel.org/r/20230411-dpu-intf-te-v4-10-27ce1a5ab5c6@somainline.orgSigned-off-by:
-
Marijn Suijten authored
A bunch of registers are indented with two extra spaces, looking as if these are values corresponding to the previous register which is not the case, rather these are simply also register offsets and should only have a single space separating them and the #define keyword. Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/534218/ Link: https://lore.kernel.org/r/20230411-dpu-intf-te-v4-9-27ce1a5ab5c6@somainline.orgSigned-off-by:
-
Marijn Suijten authored
According to various downstream sources the PCC sub-block inside DSPP is version 4.0 since DPU 4.0 and higher, including SC7[12]80 at DPU version 6.2 and 7.2 respectively. After correcting the version this struct becomes identical to sm8150_dspp_sblk which is used all across the catalog: replace uses of sc7180_dspp_sblk with that and remove the struct definition for sc7180_dspp_sblk entirely. Fixes: 4259ff7a ("drm/msm/dpu: add support for pcc color block in dpu driver") Signed-off-by:
-
Abhinav Kumar authored
Add writeback support for sc7280. This was validated with kms_writeback test case in IGT. Signed-off-by:
-
Dmitry Baryshkov authored
The driver doesn't support hsic/memcolor and pcc SSPP subblocks. Drop corresponding definitions. Signed-off-by:
-
Abhinav Kumar authored
Since GC and IGC masks have now been dropped, DSPP_MSM8998_MASK is the same as DSPP_SC7180_MASK. Since DSPP_SC7180_MASK is used more than DSPP_MSM8998_MASK, lets drop the latter. Signed-off-by:
-
Abhinav Kumar authored
Gamma Correction (GC) and Inverse Gamma Correction(IGC) is currently unused. In addition dpu_dspp_sub_blks didn't even have an igc member describing the block. Drop related code from the dpu hardware catalog otherwise this becomes a burden to carry across chipsets in the catalog. changes in v3: - drop IGC related code from dpu_hw_catalog too - update commit text accordingly Signed-off-by:
-
Abhinav Kumar authored
Inverse gamma correction blocks (IGC) are not used today so lets remove the usage of DPU_DSPP_IGC in the DSPP flush to make it easier to remove IGC from the catalog. We can add this back when IGC is properly supported in DPU with one of the standard DRM properties. changes in v3: - minor change dspp -> DSPP in commit text Signed-off-by:
-
Abhinav Kumar authored
Gamma correction blocks (GC) are not used today so lets remove the usage of DPU_DSPP_GC in the dspp flush to make it easier to remove GC from the catalog. We can add this back when GC is properly supported in DPU with one of the standard DRM properties. changes in v3: - drop the link tag which was auto added before Signed-off-by:
-
Marijn Suijten authored
The Resource Manager already iterates over all available blocks from the catalog, only to pass their ID to a dpu_hw_xxx_init() function which uses an _xxx_offset() helper to search for and find the exact same catalog pointer again to initialize the block with, fallible error handling and all. Instead, pass const pointers to the catalog entries directly to these _init functions and drop the for loops entirely, saving on both readability complexity and unnecessary cycles at boot. Signed-off-by:
-
Marijn Suijten authored
Some of these members were initialized while never read, while others were not even assigned any pointer value at all. Drop them to save some space, and above all confusion when looking at or accidentally dereferencing these members. Signed-off-by:
-
Dmitry Baryshkov authored
Stop mapping the regdma region. The driver does not support regdma. Signed-off-by:
-
Dmitry Baryshkov authored
The regdma is currently not used by the current driver. We have no way to practically verify that the regdma is described correctly. Drop it now. Signed-off-by:
-
Arnaud Vrac authored
Override the default max cursor size reported to userspace of 64x64. MSM8998 hw cursor planes support 512x512 size, and other chips use DMA SSPPs. Signed-off-by:
Arnaud Vrac <avrac@freebox.fr> Reviewed-by:
-
Arnaud Vrac authored
This matches the value for both fbdev and sde implementations in the downstream msm-4.4 repository. Signed-off-by:
-
Arnaud Vrac authored
Do not override the hsync/vsync polarity passed by the encoder when setting up intf timings. The same logic was used in both the encoder and intf code to set the DP and DSI polarities, so those interfaces are not impacted. However for HDMI, the polarities were overriden to static values based on the vertical resolution, instead of using the actual mode polarities. Signed-off-by:
-
Dmitry Baryshkov authored
MSM8998 and the older Qualcomm platforms support HDMI outputs. Now as DPU encoder is ready, add support for using INTF_HDMI. Signed-off-by:
Arnaud Vrac <rawoul@gmail.com> Tested-by: Arnaud Vrac <rawoul@gmail.com> # on msm8998 Patchwork: https://patchwork.freedesktop.org/patch/532371/ Link: https://lore.kernel.org/r/20230415171926.85774-3-dmitry.baryshkov@linaro.orgSigned-off-by:
-
- 19 May, 2023 5 commits
-
-
Dmitry Baryshkov authored
Rather than passing DRM_MODE_ENCODER_* and letting dpu_encoder to guess, which intf type we mean, pass INTF_DSI/INTF_DP directly. This is required to support HDMI output in DPU, as both DP and HDMI encoders are DRM_MODE_ENCODER_TMDS. Thus dpu_encoder code can not make a difference between HDMI and DP outputs. Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Dmitry Baryshkov authored
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL blocks, so switch it to CTL_SC7280_MASK too. Some background: original commit 100d7ef6 ("drm/msm/dpu: add support for SM8450") had all (relevant at that time) bit spelled individually. Then commit 0e91bcbb ("drm/msm/dpu: Add SM8350 to hw catalog"), despite being a mismerge, correctly changed all other CTL entries to use CTL_SC7280_MASK, except CTL_0. While the current BLOCK_SOC_MASK style is not ideal (and while we are working on a better scheme), let's follow its usage as a least minimal surprise. For example, sc8280xp, a close associate of sm8450, also uses CTL_SC7280_MASK. Signed-off-by:
-
Dmitry Baryshkov authored
Enable DSPP and DSC hardware blocks on sc8180x platform. Signed-off-by:
-
Dmitry Baryshkov authored
Mark DSPP_2 and DSPP_3 as used for LM_2 and LM_3 Fixes: 100d7ef6 ("drm/msm/dpu: add support for SM8450") Signed-off-by:
-
Dmitry Baryshkov authored
Theoretically, since sm8150 we should be using a single CTL for the split panel case, but since we do not support it for now, fallback to DPU_CTL_SPLIT_DISPLAY. Signed-off-by:
-
- 17 May, 2023 2 commits
-
-
Rob Clark authored
Otherwise it is not always obvious if a dt or iommu change is causing us to fall back to global pgtable. Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
-
Rob Clark authored
When the special handling of qcom,adreno-smmu was moved into qcom_smmu_create(), it was overlooked that we didn't have all the required entries in qcom_smmu_impl_of_match. So we stopped getting adreno_smmu_priv on sc7180, breaking per-process pgtables. Fixes: 30b912a0 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check into qcom_smmu_create") Cc: <stable@vger.kernel.org> Suggested-by:
Lepton Wu <lepton@chromium.org> Signed-off-by:
-
- 11 May, 2023 2 commits
-
-
Rob Clark authored
For errors after msm_submitqueue_get(), we need to drop the submitqueue reference. Additionally after get_unused_fd() we need to drop the fd. The ordering for dropping the queue lock and put_unused_fd() is not important, so just move this all into out_post_unlock. v2: Only drop queue ref if submit doesn't take it v3: Fix unitialized submit ref in error path v4: IS_ERR_OR_NULL() Reported-by: pinkperfect2021@gmail.com Fixes: f0de40a1 drm/msm: ("Reorder lock vs submit alloc") Signed-off-by:
-
Luca Weiss authored
In the case that no IOMMU is available, msm_iommu_new can return NULL which should be handled. Without we will get a NULL pointer dereference in the next statement when we try to use the mmu variable. Fixes: 8cceb773 ("drm/msm/adreno: stall translation on fault for all GPU families") Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Reviewed-by:
-
- 28 Apr, 2023 1 commit
-
-
Jianhua Lu authored
This fixes warning: sm8250-xiaomi-elish-csot.dtb: dsi@ae94000: Unevaluated properties are not allowed ('qcom,master-dsi', 'qcom,sync-dual-dsi' were unexpected) Reviewed-by:Rob Herring <robh@kernel.org> Signed-off-by:
Jianhua Lu <lujianhua000@gmail.com> Fixes: 4dbe55c9 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings") Reviewed-by:
-
- 26 Apr, 2023 12 commits
-
-
Marijn Suijten authored
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT registers are already defined higher up, in the right place when sorted numerically. Fixes: 25fdd593 ("drm/msm: Add SDM845 DPU support") Signed-off-by:
-
Marijn Suijten authored
Despite downstream DTS stating otherwise, the PINGPONG block has no registers starting with DPU revision 7.0.0. TEAR registers are gone since DPU 5.0.0 after being moved to the INTF block, and DSC registers are gone since 7.0.0, leaving only the dither sub-block. A future patch, part of the DSC 1.2 series, should disable DSC functions on the PINGPONG block for all DPU >= 7.0.0 hardware. Fixes: 4a352c2f ("drm/msm/dpu: Introduce SC8280XP") Fixes: 0e91bcbb ("drm/msm/dpu: Add SM8350 to hw catalog") Fixes: 100d7ef6 ("drm/msm/dpu: add support for SM8450") Signed-off-by:
-
Marijn Suijten authored
According to downstream sources this DITHER sub-block sits at an offset of 0xe0 with version 0x20000. Lets fix this by using sc7280_pp_sblk instead of sdm845_pp_sblk. Fixes: 4a352c2f ("drm/msm/dpu: Introduce SC8280XP") Fixes: 0e91bcbb ("drm/msm/dpu: Add SM8350 to hw catalog") Fixes: 100d7ef6 ("drm/msm/dpu: add support for SM8450") Signed-off-by:
-
Marijn Suijten authored
SM8550 exclusively has a DITHER sub-block inside the PINGPONG block and no other registers, hence the DITHER name of the macro and a corresponding PINGPONG block length of zero. However, the PP_BLK_ macro name was typo'd to DIPHER rather than DITHER. Fixes: efcd0107 ("drm/msm/dpu: add support for SM8550") Signed-off-by:
-
Marijn Suijten authored
Use tabs for consistency with the other interrupt register definitions, rather than spaces. Fixes: ed6154a1 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target") Fixes: 89688e21 ("drm/msm/dpu: Add more of the INTF interrupt regions") Fixes: 4a352c2f ("drm/msm/dpu: Introduce SC8280XP") Signed-off-by:
-
Marijn Suijten authored
These offsets do not fall under the MDP TOP block and do not fit the comment right above. Move them to dpu_hw_interrupts.c next to the repsective MDP_INTF_x_OFF interrupt block offsets. Fixes: 25fdd593 ("drm/msm: Add SDM845 DPU support") Signed-off-by:
-
Marijn Suijten authored
No hardware beyond kona (sm8250, DPU 6.0.0) defines the TE2 PINGPONG sub-block offset downstream, and according to insiders no DPU >= 5.0.0 hardware has support for it either. Especially since neither downstream nor upstream utilize these registers in any way, remove the erroneous specification from SM8150, SC8180X, SM8250, SC7180, SM8350, SC8280XP and SM8450 to prevent confusion. Note that downstream enables the PPSPLIT (split-FIFO) topology (single LM for 2 PP and 2 INTF) based on the presence of a TE2 block. Fixes: 386fced3 ("drm/msm/dpu: add SM8150 to hw catalog") Fixes: 7bdc0c4b ("msm:disp:dpu1: add support for display for SC7180 target") Fixes: 0e91bcbb ("drm/msm/dpu: Add SM8350 to hw catalog") Fixes: 4a352c2f ("drm/msm/dpu: Introduce SC8280XP") Fixes: 100d7ef6 ("drm/msm/dpu: add support for SM8450") Signed-off-by:
-
Marijn Suijten authored
Neither of these SoCs has INTF0, they only have a DSI interface on index 1. Stop enabling an interrupt that can't fire. Fixes: 3581b706 ("drm/msm/disp/dpu1: add support for display on SM6115") Fixes: 5334087e ("drm/msm: add support for QCM2290 MDSS") Signed-off-by:
-
Arnaud Vrac authored
Change lm blocks pairs so that lm blocks with the same features are paired together: LM_0 and LM_1 with PP and DSPP LM_2 and LM_5 with PP LM_3 and LM_4 This matches the sdm845 configuration and allows using pp or dspp when 2 lm blocks are needed in the topology. In the previous config the reservation code could never find an lm pair without a matching feature set. Signed-off-by:
-
Arnaud Vrac authored
Match the values found in the downstream msm-4.4 kernel sde driver. Signed-off-by:
-
Marijn Suijten authored
The WB debug log mask ended up never being assigned, leading to writes to this block to never be logged even if the mask is enabled in dpu_hw_util_log_mask via debugfs. Fixes: 84a33d0f ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback blocks") Signed-off-by:
-
Srinivas Kandagatla authored
while binding the code always registers a audio driver, however there is no corresponding unregistration done in unbind. This leads to multiple redundant audio platform devices if dp_display_bind and dp_display_unbind happens multiple times during startup. On X13s platform this resulted in 6 to 9 audio codec device instead of just 3 codec devices for 3 dp ports. Fix this by unregistering codecs on unbind. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Fixes: d13e36d7 ("drm/msm/dp: add audio support for Display Port on MSM") Reviewed-by:
-
- 24 Apr, 2023 1 commit
-
-
Rob Clark authored
Commit d6ae7d1c ("drm/msm/gem: Simplify vmap vs LRU tracking") introduced a splat in the pin_pages_locked() path for buffers that had been MADV_DONTNEED. ------------[ cut here ]------------ msm_obj->madv != 0 WARNING: CPU: 1 PID: 144 at drivers/gpu/drm/msm/msm_gem.c:230 msm_gem_pin_pages_locked+0x9c/0xd4 Modules linked in: lzo_rle cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core venus_dec venus_enc videobuf2_dma_contig cdc_ether usbnet mii uvcvideo videobuf2_vmalloc hci_uart btqca qcom_spmi_adc5 uvc qcom_spmi_temp_alarm qcom_vadc_common cros_ec_sensorhub videobuf2_memops cros_ec_typec sx9324 sx_common typec joydev bluetooth industrialio_triggered_buffer ecdh_generic kfifo_buf ecc venus_core qcom_stats v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath11k_ahb ath11k mac80211 cfg80211 fuse zram zsmalloc CPU: 1 PID: 144 Comm: ring0 Tainted: G W 6.3.0-rc2-debug+ #622 Hardware name: Google Villager (rev1+) with LTE (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_pin_pages_locked+0x9c/0xd4 lr : msm_gem_pin_pages_locked+0x9c/0xd4 sp : ffffffc009ffbab0 x29: ffffffc009ffbab0 x28: ffffffee8da75008 x27: ffffff80a10274d0 x26: ffffff8087fe3bf8 x25: ffffff8087fe3c08 x24: 0000000000000001 x23: ffffff80891d5800 x22: ffffff809d0de480 x21: ffffff8081e5a080 x20: 0000000000000002 x19: ffffff80a3564c00 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000000a9620 x14: 0000000000000000 x13: 2d2d2d2d2d2d2d2d x12: 2d2d2d2d5d206572 x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : ffffffee8c705dfc x8 : ffffffee8da75000 x7 : ffffffee8d34e6d0 x6 : 0000000000000000 x5 : 00000000000affa8 x4 : 000000000000000d x3 : ffffffee8da75008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8088048040 Call trace: msm_gem_pin_pages_locked+0x9c/0xd4 get_vaddr+0xb0/0x150 msm_gem_get_vaddr_active+0x1c/0x28 snapshot_buf+0x90/0x10c msm_rd_dump_submit+0x30c/0x380 msm_gpu_submit+0x88/0x174 msm_job_run+0x68/0x118 drm_sched_main+0x2b8/0x3a0 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 irq event stamp: 3358 hardirqs last enabled at (3357): [<ffffffee8c7051f4>] __up_console_sem+0x7c/0x80 hardirqs last disabled at (3358): [<ffffffee8d3480b0>] el1_dbg+0x24/0x80 softirqs last enabled at (3330): [<ffffffee8c610420>] __do_softirq+0x21c/0x4bc softirqs last disabled at (3325): [<ffffffee8c616708>] ____do_softirq+0x18/0x24 ---[ end trace 0000000000000000 ]--- But, as with msm_gem_get_vaddr_active(), this is a special case because we know that the buffer won't be purged evicted until it's fence is signaled. We just forgot to propagate the logic get_vaddr() to pin_pages_locked(). Fixes: d6ae7d1c ("drm/msm/gem: Simplify vmap vs LRU tracking") Signed-off-by:
-
