- Dec 24, 2024
-
-
Passing a variable string as a printf style format is potentially dangerous that -Wformat-security can warn about if enabled. A new instance just got added: drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function 'dpu_kms_mdp_snapshot': drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1046:49: error: format not a string literal and no format arguments [-Werror=format-security] 1046 | vbif->name); | ~~~~^~~~~~ Fix this one and the preexisting -Wformat-security warnings the in the DRM code for snapdragon. Fixes: 1a40bb31 ("drm/msm/dpu: Add VBIF to DPU snapshot") # and others Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/629126/ Link: https://lore.kernel.org/r/20241216083319.1838449-1-arnd@kernel.org Signed-off-by:
-
Add support for allocating the concurrent writeback mux as part of the WB allocation Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by:
-
Adjust the WB_MUX configuration to account for using dedicated CWB pingpong blocks. Signed-off-by:
Esha Bharadwaj <quic_ebharadw@quicinc.com> Reviewed-by:
-
The CWB mux has its own registers and set of operations. Add dpu_hw_cwb abstraction to allow driver to configure the CWB mux. Reviewed-by:
-
Implement instance of snapshot function to dump new registers used for cwb Reviewed-by:
-
Change pingpong index and names to distinguish between general use pingpong blocks and pingpong blocks dedicated for concurrent writeback Reviewed-by:
-
Add a new block for concurrent writeback mux to the SM8650 HW catalog Signed-off-by:
-
Dmitry Baryshkov authored
Up to now the driver has been using encoder to allocate hardware resources. Switch it to use CRTC id in preparation for moving resource allocation to be tied to the CRTC lifetime. Reviewed-by:
-
Dmitry Baryshkov authored
The struct dpu_rm_requirements was used to wrap display topology and hw resources, which meant INTF indices. As of commit ef58e0ad ("drm/msm/dpu: get INTF blocks directly rather than through RM") the hw resources struct was removed, leaving struct dpu_rm_requirements containing a single field (topology). Remove the useless wrapper. Signed-off-by:
-
Dmitry Baryshkov authored
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: e3b1f369 ("drm/msm/dpu: Add X1E80100 support") Reviewed-by:
-
Dmitry Baryshkov authored
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: b94747f7 ("drm/msm/dpu: add support for SM8650 DPU") Reviewed-by:
-
Dmitry Baryshkov authored
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: efcd0107 ("drm/msm/dpu: add support for SM8550") Reviewed-by:
-
Dmitry Baryshkov authored
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: 0e91bcbb ("drm/msm/dpu: Add SM8350 to hw catalog") Reviewed-by:
-
Dmitry Baryshkov authored
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: 05ae91d9 ("drm/msm/dpu: enable DSPP support on SM8[12]50") Reviewed-by:
-
Dmitry Baryshkov authored
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: f5abecfe ("drm/msm/dpu: enable DSPP and DSC on sc8180x") Reviewed-by:
-
Dmitry Baryshkov authored
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: 05ae91d9 ("drm/msm/dpu: enable DSPP support on SM8[12]50") Reviewed-by:
-
Dmitry Baryshkov authored
On SDM670 the DPU has two DSPP blocks compared to 4 DSPP blocks on SDM845. Currently SDM670 just reuses LMs and DSPPs from SDM845. Define platform-specific configuration for those blocks. Fixes: e140b7e4 ("drm/msm/dpu: Add hw revision 4.1 (SDM670)") Reviewed-by:
-
- Dec 22, 2024
-
-
Dmitry Baryshkov authored
The dp_audio module doesn't make any use of the passed DP panel instance. Drop the argument. Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> # sc7180-trogdor Reviewed-by:
-
Dmitry Baryshkov authored
All other submodules pass arguments directly. Drop struct msm_dp_panel_in that is used to wrap dp_panel's submodule args and pass all data to msm_dp_panel_get() directly. Reviewed-by:
-
Dmitry Baryshkov authored
Drop obsolete functions to access audio packet headers. The dp_audio.c now writes them using msm_dp_write_link() directly. Reviewed-by:
-
Dmitry Baryshkov authored
Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly to program audio packet data. Use 0 as Packet ID, as it was not programmed earlier. Signed-off-by:
-
Dmitry Baryshkov authored
The msm_dp_panel_dump_regs() and msm_dp_catalog_dump_regs() are not called anywhere. If there is a necessity to dump registers, the snapshotting should be used instead. Drop these two functions. Reviewed-by:
-
- Dec 15, 2024
-
-
Dmitry Baryshkov authored
Make dpu_rm_print_state() also output the SSPP allocation state. Reviewed-by:
-
Dmitry Baryshkov authored
Virtual wide planes give high amount of flexibility, but it is not always enough: In parallel multirect case only the half of the usual width is supported for tiled formats. Thus the whole width of two tiled multirect rectangles can not be greater than max_linewidth, which is not enough for some platforms/compositors. Another example is as simple as wide YUV plane. YUV planes can not use multirect, so currently they are limited to max_linewidth too. Now that the planes are fully virtualized, add support for allocating two SSPP blocks to drive a single DRM plane. This fixes both mentioned cases and allows all planes to go up to 2*max_linewidth (at the cost of making some of the planes unavailable to the user). Signed-off-by:
-
Dmitry Baryshkov authored
Only several SSPP blocks support such features as YUV output or scaling, thus different DRM planes have different features. Properly utilizing all planes requires the attention of the compositor, who should prefer simpler planes to YUV-supporting ones. Otherwise it is very easy to end up in a situation when all featureful planes are already allocated for simple windows, leaving no spare plane for YUV playback. To solve this problem make all planes virtual. Each plane is registered as if it supports all possible features, but then at the runtime during the atomic_check phase the driver selects backing SSPP block for each plane. As the planes are attached to the CRTC and not the encoder, the SSPP blocks are also allocated per CRTC ID (all other resources are currently allocated per encoder ID). This also matches the hardware requirement, where both rectangles of a single SSPP can only be used with the LM pair. Note, this does not provide support for using two different SSPP blocks for a single plane or using two rectangles of an SSPP to drive two planes. Each plane still gets its own SSPP and can utilize either a solo rectangle or both multirect rectangles depending on the resolution. Note #2: By default support for virtual planes is turned off and the driver still uses old code path with preallocated SSPP block for each plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1' kernel parameter. Reviewed-by:
-
Add support for DSI 2.3.1 (block used on SM6150). Signed-off-by:
Li Liu <quic_lliu6@quicinc.com> Signed-off-by:
Fange Zhang <quic_fangez@quicinc.com> Reviewed-by:
-
Add phy configuration for SM6150 Reviewed-by:
-
Add definitions for the display hardware used on the Qualcomm SM6150 platform. Reviewed-by:
-
Add support for MDSS on SM6150. Reviewed-by:
-
Document the MDSS and DPU hardware found on the Qualcomm SM6150 platform. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/628003/ Link: https://lore.kernel.org/r/20241210-add-display-support-for-qcs615-platform-v4-3-2d875a67602d@quicinc.com Signed-off-by:
-
Document general compatibility of the DSI controller on SM6150. Signed-off-by:
-
Add new compatible for SM6150 with dsi_phy_14nm_36mA_regulators Acked-by:
-
On chipsets such as QCS615, there is no 3dmux present. In such a case, a layer exceeding the max_mixer_width cannot be split, hence cannot be supported. Filter out the modes which exceed the max_mixer_width when there is no 3dmux present. Also, add a check in the dpu_crtc_atomic_check() to return failure for such modes. Signed-off-by:
-
Dmitry Baryshkov authored
The macrotile_mode is a flag, not a bit value. Use true/false values to set it rather than 1/0. Reviewed-by:
-
Dmitry Baryshkov authored
Follow other msm_mdss_setup_ubwc_dec_nn functions and use individual bits instead of just specifying the value to be programmed to the UBWC_STATIC register. Signed-off-by:
-
Dmitry Baryshkov authored
Rather than hand-coding UBWC_STATIC value calculation, define corresponding bitfields and use them to setup the register value. Signed-off-by:
-
Add VBIF registers to the DPU snapshot to help with debugging. Signed-off-by:
-
- Dec 12, 2024
-
-
Abhinav Kumar authored
Similar to the r_pipe sspp protect, add a check to protect the pipe state prints to avoid NULL ptr dereference for cases when the state is dumped without a corresponding atomic_check() where the pipe->sspp is assigned. Fixes: 31f7148f ("drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check") Reported-by:
Douglas Anderson <dianders@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> # sc7180-trogdor Patchwork: https://patchwork.freedesktop.org/patch/628404/ Link: https://lore.kernel.org/r/20241211-check-state-before-dump-v2-1-62647a501e8c@quicinc.com Signed-off-by:
-
During suspend/resume process all connectors are explicitly disabled and then reenabled. However resume fails because of the connector_status check: [dpu error]connector not connected 3 [drm:drm_mode_config_helper_resume [drm_kms_helper]] *ERROR* Failed to resume (-22) It doesn't make sense to check for the Writeback connected status (and other drivers don't perform such check), so drop the check. It wasn't a problem before the commit 71174f36 ("drm/msm/dpu: move writeback's atomic_check to dpu_writeback.c"), since encoder's atomic_check() is called under a different conditions that the connector's atomic_check() (e.g. it is not called if there is no connected CRTC or if the corresponding connector is not a part of the new state). Fixes: 71174f36 ("drm/msm/dpu: move writeback's atomic_check to dpu_writeback.c") Cc: stable@vger.kernel.org Reported-by:
Leonard Lausen <leonard@lausen.nl> Closes: drm/msm#57 Tested-by: Leonard Lausen <leonard@lausen.nl> # on sc7180 lazor Tested-by:
György Kurucz <me@kuruczgy.com> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Tested-by:
-
Abhinav Kumar authored
dp_ctrl_off_link() was created to handle a case where we received a cable connect and then get a cable disconnect without the corresponding dp_display_enable(). For such cases the pixel clock will be off but the link clock will still be on. dp_ctrl_off_link() handles this case by turning off the link clock only. However, the vote removal to the opp table for this case was missed. Remove the opp table vote in dp_ctrl_off_link(). Fixes: 375a1260 ("drm/msm/dp: tear down main link at unplug handle immediately") Reviewed-by:
-
