- 15 Oct, 2024 2 commits
-
-
Jessica Zhang authored
Only program the merge_3d block for the video phys encoder when the 3d blend mode is not NONE Fixes: 3e79527a ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250") Suggested-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/619095/ Link: https://lore.kernel.org/r/20241009-merge3d-fix-v1-1-0d0b6f5c244e@quicinc.comSigned-off-by:
-
Jessica Zhang authored
Don't set the merge_3d pending flush bits if the mode_3d is BLEND_3D_NONE. Always flushing merge_3d can cause timeout issues when there are multiple commits with concurrent writeback enabled. This is because the video phys enc waits for the hw_ctl flush register to be completely cleared [1] in its wait_for_commit_done(), but the WB encoder always sets the merge_3d pending flush during each commit regardless of if the merge_3d is actually active. This means that the hw_ctl flush register will never be 0 when there are multiple CWB commits and the video phys enc will hit vblank timeout errors after the first CWB commit. [1] commit fe9df3f5 ("drm/msm/dpu: add real wait_for_commit_done()") Fixes: 3e79527a ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250") Fixes: d7d0e73f ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/619092/ Link: https://lore.kernel.org/r/20241009-mode3d-fix-v1-1-c0258354fadc@quicinc.comSigned-off-by:
-
- 14 Oct, 2024 8 commits
-
-
Douglas Anderson authored
With the "drm/msm: add a display mmu fault handler" series [1] we saw issues in the field where memory allocation was failing when allocating space for registers in msm_disp_state_dump_regs(). Specifically we were seeing an order 5 allocation fail. It's not surprising that order 5 allocations will sometimes fail after the system has been up and running for a while. There's no need here for contiguous memory. Change the allocation to kvzalloc() which should make it much less likely to fail. [1] https://lore.kernel.org/r/20240628214848.4075651-1-quic_abhinavk@quicinc.com/ Fixes: 98659487 ("drm/msm: add support to take dpu snapshot") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
Douglas Anderson authored
If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since "dump_addr" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print "Registers not stored" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Fixes: 98659487 ("drm/msm: add support to take dpu snapshot") Signed-off-by: -
Jonathan Marek authored
When (mode->clock * 1000) is larger than (1<<31), int to unsigned long conversion will sign extend the int to 64 bits and the pclk_rate value will be incorrect. Fix this by making the result of the multiplication unsigned. Note that above (1<<32) would still be broken and require more changes, but its unlikely anyone will need that anytime soon. Fixes: c4d8cfe5 ("drm/msm/dsi: add implementation for helper functions") Signed-off-by:
Jonathan Marek <jonathan@marek.ca> Reviewed-by:
-
Jonathan Marek authored
drm_mode_vrefresh() can introduce a large rounding error, avoid it. Fixes: 7c9e4a55 ("drm/msm/dsi: Reduce pclk rate for compression") Signed-off-by:
-
Dmitry Baryshkov authored
The pll_cmp_to_fdata() was never used by the working code. Drop it to prevent warnings with W=1 and clang. Reported-by:
Jani Nikula <jani.nikula@intel.com> Closes: https://lore.kernel.org/dri-devel/3553b1db35665e6ff08592e35eb438a574d1ad65.1725962479.git.jani.nikula@intel.comSigned-off-by:
-
Dmitry Baryshkov authored
Make _dpu_crtc_setup_lm_bounds() check that CRTC width is not overflowing LM requirements. Rename the function accordingly. Fixes: 25fdd593 ("drm/msm: Add SDM845 DPU support") Reviewed-by:
-
Dmitry Baryshkov authored
Historically CRTC resources (LMs and CTLs) were assigned in dpu_crtc_atomic_begin(). The commit 9222cdd2 ("drm/msm/dpu: move hw resource tracking to crtc state") simply moved resources to struct dpu_crtc_state, without changing the code sequence. Later on the commit b107603b ("drm/msm/dpu: map mixer/ctl hw blocks in encoder modeset") rearanged the code, but still kept the cstate->num_mixers assignment to happen during commit phase. This makes dpu_crtc_state inconsistent between consequent atomic_check() calls. Move CRTC resource assignment to happen at the end of dpu_encoder_virt_atomic_check(). Fixes: b107603b ("drm/msm/dpu: map mixer/ctl hw blocks in encoder modeset") Signed-off-by:
-
Dmitry Baryshkov authored
The commit b954fa6b ("drm/msm/dpu: Refactor rm iterator") removed zero-init of the hw_ctl array, but didn't change the error condition, that checked for hw_ctl[i] being NULL. At the same time because of the early returns in case of an error dpu_encoder_phys might be left with the resources assigned in the previous state. Rework assigning of hw_pp / hw_ctl to the dpu_encoder_phys in order to make sure they are always set correctly. Fixes: b954fa6b ("drm/msm/dpu: Refactor rm iterator") Suggested-by:
-
- 01 Sep, 2024 24 commits
-
-
Dmitry Baryshkov authored
Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Patchwork: https://patchwork.freedesktop.org/patch/570194/ Link: https://lore.kernel.org/r/20231203003203.1293087-5-dmitry.baryshkov@linaro.org
-
Dmitry Baryshkov authored
Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by:
-
Dmitry Baryshkov authored
Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by:
-
Dmitry Baryshkov authored
Enable WB2 hardware block, enabling writeback support on this platform. Reviewed-by:
-
Sherry Yang authored
The following build error was triggered because of NULL string argument: BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c: In function 'mdp5_smp_dump': BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=] BUILDSTDERR: 352 | drm_printf(p, "%s:%d\t%d\t%s\n", BUILDSTDERR: | ^~ BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=] This happens from the commit a61ddb43 ("drm: enable (most) W=1 warnings by default across the subsystem"). Using "(null)" instead to fix it. Fixes: bc5289ee ("drm/msm/mdp5: add debugfs to show smp block status") Signed-off-by:
Sherry Yang <sherry.yang@oracle.com> Reviewed-by:
-
Dmitry Baryshkov authored
According to the display-drivers, 5nm DSI PLL (v4.2, v4.3) have different boundaries for pll_clock_inverters programming. Follow the vendor code and use correct values. Fixes: 2f9ae4e3 ("drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450") Signed-off-by:
-
Abhinav Kumar authored
Hardware document indicates that widebus is recommended on DP on all MDSS chipsets starting version 5.x.x and above. Follow the guideline and mark widebus support on all relevant chipsets for DP. Fixes: 766f7052 ("drm/msm/dp: Remove now unused connector_type from desc") Fixes: 1b2d98bd ("drm/msm/dp: Add DisplayPort controller for SM8650") Signed-off-by:
-
Arnaud Vrac authored
Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC. This code is mostly copy & paste of the vendor code from msm-4.4 kernel.lnx.4.4.r38-rel. Signed-off-by:
Arnaud Vrac <avrac@freebox.fr> Reviewed-by:
Marc Gonzalez <mgonzalez@freebox.fr> Patchwork: https://patchwork.freedesktop.org/patch/605631/ Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-4-e44a20553464@freebox.fr [DB: replaced division with do_div64 to fix build issues on ARM32] Signed-off-by:
-
Marc Gonzalez authored
Current driver already supports the msm8998 HDMI TX. We just need to add the compatible string. Reviewed-by:
-
Marc Gonzalez authored
HDMI TX block embedded in the APQ8098. Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Marc Gonzalez authored
HDMI PHY block embedded in the APQ8098. Acked-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Dmitry Baryshkov authored
Some platforms provides a mechanism for configuring the mapping between (one or two) DisplayPort intfs and their PHYs. In particular SC8180X requires this to be configured, since on this platform there are fewer controllers than PHYs. The change implements the logic for optionally configuring which PHY each of the DP INTFs should be connected to and marks the SC8180X DPU to program 2 entries. For now the request is simply to program the mapping 1:1, any support for alternative mappings is left until the use case arrise. Note that e.g. msm-4.14 unconditionally maps INTF 0 to PHY 0 on all platforms, so perhaps this is needed in order to get DisplayPort working on some other platforms as well. Co-developed-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
-
Otto Pflüger authored
Add support for Adreno 306A GPU what is found in MSM8917 SoC. This GPU marketing name is Adreno 308. Signed-off-by:
Otto Pflüger <otto.pflueger@abscue.de> [use internal name of the GPU, reword the commit message] Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Barnabás Czémán <trabarni@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/605403/Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
A621 is a clear A662 derivative (same lineage as A650), no explosions or sick features, other than a NoC bug which can stall the GPU.. Add support for it. Signed-off-by:
-
Konrad Dybcio authored
This was apparently never done before.. Program the expected values. This also gets rid of sneakily setting that register through the HWCG reg list on A690. Signed-off-by:
-
Konrad Dybcio authored
This register's magic value differs wildly between different GPUs, use the hardcoded data instead of trying to make some logic out of it. Signed-off-by:
-
Konrad Dybcio authored
Store the correct values that we happen to have for some A7xx SKUs in the GPU info struct and fill out the missing information for A6xx GPUs based on downstream kernel information. Signed-off-by:
-
Konrad Dybcio authored
The if-else monster is so unmaintainable that one case is repeated twice. Get rid of it. Signed-off-by:
-
Konrad Dybcio authored
A650 family includes A660 family (they've got a big family), A650 itself, and some more A6XX_GEN3 SKUs, all of which should fall into the same branch of the if-condition. Simplify that. Signed-off-by:
-
Vladimir Lypak authored
There is another cause for soft lock-up of GPU in empty ring-buffer: race between GPU executing last commands and CPU checking ring for emptiness. On GPU side IRQ for retire is triggered by CACHE_FLUSH_TS event and RPTR shadow (which is used to check ring emptiness) is updated a bit later from CP_CONTEXT_SWITCH_YIELD. Thus if GPU is executing its last commands slow enough or we check that ring too fast we will miss a chance to trigger switch to lower priority ring because current ring isn't empty just yet. This can escalate to lock-up situation described in previous patch. To work-around this issue we keep track of last submit sequence number for each ring and compare it with one written to memptrs from GPU during execution of CACHE_FLUSH_TS event. Fixes: b1fc2839 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by:
Vladimir Lypak <vladimir.lypak@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/612047/Signed-off-by:
-
Vladimir Lypak authored
On A5XX GPUs when preemption is used it's invietable to enter a soft lock-up state in which GPU is stuck at empty ring-buffer doing nothing. This appears as full UI lockup and not detected as GPU hang (because it's not). This happens due to not triggering preemption when it was needed. Sometimes this state can be recovered by some new submit but generally it won't happen because applications are waiting for old submits to retire. One of the reasons why this happens is a race between a5xx_submit and a5xx_preempt_trigger called from IRQ during submit retire. Former thread updates ring->cur of previously empty and not current ring right after latter checks it for emptiness. Then both threads can just exit because for first one preempt_state wasn't NONE yet and for second one all rings appeared to be empty. To prevent such situations from happening we need to establish guarantee for preempt_trigger to make decision after each submit or retire. To implement this we serialize preemption initiation using spinlock. If switch is already in progress we need to re-trigger preemption when it finishes. Fixes: b1fc2839 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by:
-
Vladimir Lypak authored
Two fields of preempt_record which are used by CP aren't reset on resume: "data" and "info". This is the reason behind faults which happen when we try to switch to the ring that was active last before suspend. In addition those faults can't be recovered from because we use suspend and resume to do so (keeping values of those fields again). Fixes: b1fc2839 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by:
-
Vladimir Lypak authored
Fine grain preemption (switching from/to points within submits) requires extra handling in command stream of those submits, especially when rendering with tiling (using GMEM). However this handling is missing at this point in mesa (and always was). For this reason we get random GPU faults and hangs if more than one priority level is used because local preemption is enabled prior to executing command stream from submit. With that said it was ahead of time to enable local preemption by default considering the fact that even on downstream kernel it is only enabled if requested via UAPI. Fixes: a7a4c19c ("drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register") Signed-off-by:
-
Konrad Dybcio authored
There are some cases, such as the one uncovered by Commit 46d4efcc ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Signed-off-by:
-
- 30 Aug, 2024 6 commits
-
-
Aleksandr Mishin authored
In adreno_request_fw() when debugging information is printed to the log after firmware load, an incorrect filename is printed. 'newname' is used instead of 'fwname', so prefix "qcom/" is being added to filename. Looks like "copy-paste" mistake. Fix this mistake by replacing 'newname' with 'fwname'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2c41ef1b ("drm/msm/adreno: deal with linux-firmware fw paths") Signed-off-by:
Aleksandr Mishin <amishin@t-argos.ru> Reviewed-by:
-
Connor Abbott authored
Make it match the MDSS settings for sc8180x and downstream. Note that without the previous commit that exposes the value of macrotile_mode to mesa, this will break mesa which expects the legacy default value of 0. Therefore we do *not* want to backport it. Signed-off-by:
Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/607398/Signed-off-by:
-
Connor Abbott authored
This adds extra parameters that affect UBWC tiling that will be used by the Mesa implementation of VK_EXT_host_image_copy. Signed-off-by:
-
Connor Abbott authored
According to downstream we should be setting RBBM_NC_MODE_CNTL to a non-default value on a663 and a680, we don't support a663 and on a680 we're leaving it at the wrong (suboptimal) value. Just set it on all GPUs. Similarly, plumb through level2_swizzling_dis which will be necessary on a663. ubwc_mode is expanded and renamed to ubwc_swizzle to match the name on the display side. Similarly macrotile_mode should match the display side. Signed-off-by:
-
Connor Abbott authored
Update to Mesa commit 36a13d2b3b0 ("freedreno: fix a7xx perfcntr countables"). Signed-off-by: -
Connor Abbott authored
This was missed because we weren't using the a750-specific indexed regs. Fixes: f3f8207d ("drm/msm: Add devcoredump support for a750") Signed-off-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/607394/Signed-off-by:
-
