- 27 Jul, 2023 10 commits
-
-
Abhinav Kumar authored
Instead of using a feature bit to decide whether to enable data compress or not for DSC use-cases, use dpu core's major version instead by assigning the enable_compression op based on the dpu core's major version. To make this possible pass the struct dpu_mdss_version to dpu_hw_intf_init(). This will avoid defining feature bits for every bit level details of registers. changes in v5: - none Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/546803/ Link: https://lore.kernel.org/r/20230712012003.2212-3-quic_abhinavk@quicinc.comSigned-off-by:
-
Abhinav Kumar authored
Introduce the dpu core revision back as an entry to the catalog so that we can just use dpu revision checks and enable those bits which should be enabled unconditionally and not controlled by a catalog and also simplify the changes to do something like: if (dpu_core_revision > xxxxx && dpu_core_revision < xxxxx) enable the bit; changes in v5: - fix the commit text to remove instances of DPU_HW_VER Reviewed-by:
-
Jessica Zhang authored
During a frame transfer in command mode, there could be frequent LP11 <-> HS transitions when multiple DCS commands are sent mid-frame or if the DSI controller is running on slow clock and is throttled. To minimize frame latency due to these transitions, it is recommended to send the frame in a single burst. This feature is supported for DSI 6G 1.3 and above, thus enable burst mode if supported. Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by:
-
Dmitry Baryshkov authored
It looks like DP controlled on SM8250 is the same as DP controller on SM8350. Use the SM8350 compatible as fallback for SM8250. Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/546242/ Link: https://lore.kernel.org/r/20230709041926.4052245-2-dmitry.baryshkov@linaro.org
-
Ryan McCann authored
Currently, the device core dump mechanism does not dump registers of sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit dpu_kms_mdp_snapshot function to account for sub-blocks. Signed-off-by:
Ryan McCann <quic_rmccann@quicinc.com> Reviewed-by:
-
Ryan McCann authored
Currently, the names of main blocks are hardcoded into the msm_disp_snapshot_add_block function rather than using the name that already exists in the catalog. Change this to take the name directly from the catalog instead of hardcoding it. Signed-off-by:
-
Ryan McCann authored
For a device core dump, the registers of sub-blocks are printed under a title formatted as <mainBlkName_sblkName>. For example, the csc sub-block for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The title is clearly redundant due to the duplicate "sspp" and "0" that exist in both the mainBlkName and sblkName. To eliminate this redundancy, remove the secondary "sspp" and "0" that exist in the sub-block name by elimanting the "sspp_" prefix and the concatenation of "num" that results in the redundant "0" suffix. Remove num parameter altogether from relevant macros as a consequence of it no longer being used. Reviewed-by:
-
Ryan McCann authored
Some sub-blocks in the hw catalog have not been given a name, so when the registers from that block are dumped, there is no name to reference. Define names for relevant sub-blocks to fix this. Reviewed-by:
-
Ryan McCann authored
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block macros. Update calls to relevant macros to reflect change. Reviewed-by:
-
Ryan McCann authored
Device core dump add block method adds hardware blocks to dumping queue with stack behavior which causes the hardware blocks to be printed in reverse order. Change the addition to dumping queue data structure from "list_add" to "list_add_tail" for FIFO queue behavior. Fixes: 98659487 ("drm/msm: add support to take dpu snapshot") Reviewed-by:
-
- 11 Jul, 2023 26 commits
-
-
Dmitry Baryshkov authored
The INTF_SDM845_MASK features mask is zero. Drop it completely. Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Tested-by:
-
Dmitry Baryshkov authored
The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely. Reviewed-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
Shift dpu_ctl_cfg contents to correct the indentation of CTL blocks. This is done in preparation to expanding the rest of hardware block defines, so that all blocks have similar indentation. Reviewed-by:
-
Dmitry Baryshkov authored
Drop useless zero assignments to the dpu_ctl_cfg::features field. Reviewed-by:
-
Dmitry Baryshkov authored
Drop useless zero assignments to the dpu_mdp_cfg::features field. Reviewed-by:
-
Dmitry Baryshkov authored
Use more standard initialisation for .clk_ctrls definitions. Define a single .clk_ctrls field and use array init inside. Reviewed-by:
-
Dmitry Baryshkov authored
Since there is always just a single MDP_TOP instance, drop the enum dpu_mdp and corresponding index value. Reviewed-by:
-
Dmitry Baryshkov authored
There is always a single MDP TOP block. Drop the mdp_count field and stop declaring dpu_mdp_cfg instances as arrays. Tested-by:
-
Dmitry Baryshkov authored
For each LM there is at max 1 peer LM. Thus there is no need to have a mask for the peer LM enumeration. Change that to have an ID of the peer LM. Reviewed-by:
-
Dmitry Baryshkov authored
In several catalog entries we did not use existing MSM_DP_CONTROLLER_n constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n for DSI interfaces. Reviewed-by:
-
Dmitry Baryshkov authored
Follow the DP example and define MSM_DSI_CONTROLLER_n enumeration. Reviewed-by:
-
Konrad Dybcio authored
Consume the refgen supply on configurations that may use it. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
-
Konrad Dybcio authored
DSI host needs REFGEN to be enabled (if it's present on a given platform). Allow consuming it. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Neil Armstrong authored
Document the optional displayport controller subnode of the SM8550 MDSS. Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
-
Neil Armstrong authored
Document the optional displayport controller subnode of the SM8450 MDSS. Acked-by:
-
Neil Armstrong authored
Document the optional displayport controller subnode of the SM8350 MDSS. Acked-by:
-
Kuogee Hsieh authored
Since struct drm_dsc_config is stored at atomic_enable() instead of display setup time during boot up, saving struct drm_dsc_config at struct msm_display_info is not necessary. Lets drop the dsc member from struct msm_display_info. Changes in v4: -- fix "Since" at commit text Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
-
Kuogee Hsieh authored
Currently struct drm_dsc_config for DSI is populated at display setup during system boot up. This mechanism works fine with embedded display but not for pluggable displays as the struct drm_dsc_config will become stale once external display is unplugged. In preparation of adding support for DP DSC support move storing of DSI DSC struct to atomic_enable() so that same mechanism will work for both embedded display and pluggable displays. Changes in v4: -- fix checkpatch.pl warning Changes in v5: -- delete dpu_encoder_get_dsc_config() from atomic_mode_set Signed-off-by:
-
- 10 Jul, 2023 2 commits
-
-
Dmitry Baryshkov authored
The array of CRTC in the struct msm_drm_private duplicates a list of CRTCs in the drm_device. Drop it and use the existing list for CRTC enumeration. Signed-off-by:
-
Konrad Dybcio authored
SDM845 was the first SoC to include both PCC v4 and GC v1.8. We don't currently support any other blocks but the common config for these two can be reused for a large amount of SoCs. Rename it to indicate the origin of that combo. Signed-off-by:
-
- 18 Jun, 2023 2 commits
-
-
Konrad Dybcio authored
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125 (trinket) and SM6225 (khaje). Trinket does not support speed binning (only a single SKU exists) and we don't yet support khaje upstream. Hence, add a fuse mapping table for bengal to allow for per-chip frequency limiting. Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375 (blair). This is what seems to be a first occurrence of this happening, but it's easy to overcome by guarding the SoC-specific fuse values with of_machine_is_compatible(). Do just that to enable frequency limiting on these SoCs. Reviewed-by:
-
