- 27 Jul, 2023 20 commits
-
-
Marijn Suijten authored
Document the SM6125 MDSS. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/548976/ Link: https://lore.kernel.org/r/20230723-sm6125-dpu-v4-9-a3f287dd6c07@somainline.orgSigned-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Marijn Suijten authored
SM6125 is identical to SM6375 including the throttle clock that is also provided to the MDP node downstream. Note that any SoC other than SM6375 (currently SC7180 and SM6350) has an unconstrained maximum number of clocks and could either pass or leave out this "throttle" clock. Signed-off-by:
-
Marijn Suijten authored
Document general compatibility of the DSI controller on SM6125. Reviewed-by:
-
Marijn Suijten authored
On SM6125 the dispcc block is gated behind VDDCX: allow this domain to be configured. Acked-by:
-
Marijn Suijten authored
The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will be passed from DT, and should be required by the bindings. Fixes: 8397c9c0 ("dt-bindings: clock: add QCOM SM6125 display clock bindings") Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marijn Suijten authored
Both SM6350 and SM6375 support only a single DSI link, and don't have a corresponding dsi1 node in DTS. Their examples should not suggest an output interface port on the display-controller node to this inexistant DSI host, with a dsi1_in label reference that doesn't exist in the example either. Fixes: 3b7502b0 ("dt-bindings: display/msm: Add SM6350 MDSS") Fixes: 2a5c1021 ("dt-bindings: display/msm: Add SM6375 MDSS") Signed-off-by:
-
Marijn Suijten authored
The regulator setup was likely copied from other SoCs by mistake. Just like SM6125 the DSI PHY on this platform is not getting power from a regulator but from the MX power domain. Fixes: 572e9fd6 ("drm/msm/dsi: Add phy configuration for QCM2290") Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
-
Abhinav Kumar authored
Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS from the catalog completely. Signed-off-by:
-
Abhinav Kumar authored
Rename the intf's enable_compression() op to program_intf_cmd_cfg() and allow it to accept a struct intf_cmd_mode_cfg to program all the bits at once. This can be re-used by widebus later on as well as it touches the same register. changes in v5: - rename struct intf_cmd_mode_cfg to dpu_hw_intf_cmd_mode_cfg - remove couple of comments Signed-off-by:
-
Abhinav Kumar authored
dpu_hw_intf has a few instances of structs which do not have the dpu_hw prefix. Lets fix this by renaming those structs and updating the usage of those accordingly. Signed-off-by:
-
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:
-
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:
-
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 20 commits
-
-
Dmitry Baryshkov authored
The INTF_SDM845_MASK features mask is zero. Drop it completely. Reviewed-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:
-
