aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-08-02drm/msm/dpu: split interrupt address arraysDmitry Baryshkov2-38/+72
There is no point in having a single enum (and a single array) for both DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single enum and two IRQ address arrays. Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Fixes: c7314613226a0 ("drm/msm: Add missing struct identifier") Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/549653/ Link: https://lore.kernel.org/r/[email protected]
2023-08-02drm/msm/dpu: inline __intr_offsetDmitry Baryshkov1-7/+1
Inline __intr_offset(), there is no point in having a separate oneline function for setting base block address. Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/549655/ Link: https://lore.kernel.org/r/[email protected]
2023-08-02drm/msm: Remove redundant DRM_DEV_ERROR()Ruan Jinjie2-2/+0
There is no need to call the DRM_DEV_ERROR() function directly to print a custom message when handling an error from platform_get_irq() function as it is going to display an appropriate error message in case of a failure. Signed-off-by: Ruan Jinjie <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/549499/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-08-02dt-bindings: display/msm: mdss-common: add memory-region propertyAmit Pundir1-0/+6
Add and document the reserved memory region property in the mdss-common schema. For now (sdm845-db845c), it points to a framebuffer memory region reserved by the bootloader for splash screen. Acked-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Amit Pundir <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/549376/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dsi: Reuse QCM2290 14nm DSI PHY configuration for SM6125Marijn Suijten1-0/+2
SM6125 features only a single PHY (despite a secondary PHY PLL source being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream sources for this "trinket" SoC do not define the typical "vcca" regulator to be available nor used. This, including the register offset is identical to QCM2290, whose config struct can trivially be reused. Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548980/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: msm: dsi-phy-14nm: Document SM6125 variantMarijn Suijten1-0/+11
Document availability of the 14nm DSI PHY on SM6125. Note that this compatible uses the SoC-suffix variant, intead of postfixing an arbitrary number without the sm/sdm portion. The PHY is not powered by a vcca regulator like on most SoCs, but by the MX power domain that is provided via the power-domains property and a single corresponding required-opps. Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548979/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/mdss: Add SM6125 supportMarijn Suijten1-0/+8
SM6125 has an UBWC 3.0 decoder but only an UBWC 1.0 encoder. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548974/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: Add SM6125 supportMarijn Suijten4-0/+245
Add definitions for the display hardware used on the Qualcomm SM6125 platform. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548978/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: display/msm: Add SM6125 MDSSMarijn Suijten1-0/+213
Document the SM6125 MDSS. Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548976/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: display/msm: sc7180-dpu: Describe SM6125Marijn Suijten1-1/+4
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 <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548972/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: display/msm: dsi-controller-main: Document SM6125Marijn Suijten1-0/+2
Document general compatibility of the DSI controller on SM6125. Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548968/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: clock: qcom, dispcc-sm6125: Allow power-domains propertyMarijn Suijten1-0/+16
On SM6125 the dispcc block is gated behind VDDCX: allow this domain to be configured. Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548970/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clockMarijn Suijten1-2/+6
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: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock bindings") Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548966/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: display/msm: Remove DSI1 ports from SM6350/SM6375 exampleMarijn Suijten2-14/+0
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: 3b7502b0c205 ("dt-bindings: display/msm: Add SM6350 MDSS") Fixes: 2a5c1021bc77 ("dt-bindings: display/msm: Add SM6375 MDSS") Signed-off-by: Marijn Suijten <[email protected]> Acked-by: Rob Herring <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548961/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dsi: Drop unused regulators from QCM2290 14nm DSI PHY configMarijn Suijten1-2/+0
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: 572e9fd6d14a ("drm/msm/dsi: Add phy configuration for QCM2290") Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/548959/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: drop DPU_INTF_DATA_COMPRESS from dpu catalogAbhinav Kumar2-3/+1
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546808/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: rename enable_compression() to program_intf_cmd_cfg()Abhinav Kumar3-7/+18
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546806/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: rename all hw_intf structs to have dpu_hw prefixAbhinav Kumar3-18/+18
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546805/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: use dpu core's major version to enable data compressAbhinav Kumar3-6/+7
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 <[email protected]> Signed-off-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546803/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: re-introduce dpu core revision to the catalogAbhinav Kumar16-2/+105
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: Dmitry Baryshkov <[email protected]> Signed-off-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546801/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dsi: Enable BURST_MODE for command mode for DSI 6G v1.3+Jessica Zhang1-0/+7
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/544551/ Link: https://lore.kernel.org/r/[email protected] [DB: fixed indentation] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27dt-bindings: display: msm: dp-controller: document SM8250 compatibleDmitry Baryshkov1-0/+1
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: Dmitry Baryshkov <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546242/ Link: https://lore.kernel.org/r/[email protected]
2023-07-27drm/msm/dpu: Update dev core dump to dump registers of sub-blocksRyan McCann1-12/+54
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546192/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: Refactor printing of main blocks in device core dumpRyan McCann1-8/+8
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 <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546194/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: Remove redundant prefix/suffix in name of sub-blocksRyan McCann1-25/+25
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: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Ryan McCann <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546198/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: Define names for unnamed sblksRyan McCann1-10/+10
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: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Ryan McCann <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546199/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm/dpu: Drop unused num argument from relevant macrosRyan McCann1-10/+10
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block macros. Update calls to relevant macros to reflect change. Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Ryan McCann <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546196/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-27drm/msm: Update dev core dump to not print backwardsRyan McCann1-1/+1
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: 98659487b845 ("drm/msm: add support to take dpu snapshot") Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Ryan McCann <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546200/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-07-26drm/msm: Disallow submit with fence id 0Rob Clark1-1/+1
A fence id of zero is expected to be invalid, and is not removed from the fence_idr table. If userspace is requesting to specify the fence id with the FENCE_SN_IN flag, we need to reject a zero fence id value. Fixes: 17154addc5c1 ("drm/msm: Add MSM_SUBMIT_FENCE_SN_IN") Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/549180/
2023-07-17drm/msm: Fix hw_fence error path cleanupRob Clark2-1/+19
In an error path where the submit is free'd without the job being run, the hw_fence pointer is simply a kzalloc'd block of memory. In this case we should just kfree() it, rather than trying to decrement it's reference count. Fortunately we can tell that this is the case by checking for a zero refcount, since if the job was run, the submit would be holding a reference to the hw_fence. Fixes: f94e6a51e17c ("drm/msm: Pre-allocate hw_fence") Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/547088/
2023-07-17drm/msm: Fix IS_ERR_OR_NULL() vs NULL check in a5xx_submit_in_rb()Gaosheng Cui1-1/+1
The msm_gem_get_vaddr() returns an ERR_PTR() on failure, and a null is catastrophic here, so we should use IS_ERR_OR_NULL() to check the return value. Fixes: 6a8bd08d0465 ("drm/msm: add sudo flag to submit ioctl") Signed-off-by: Gaosheng Cui <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Akhil P Oommen <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/547712/ Signed-off-by: Rob Clark <[email protected]>
2023-07-15drm/msm/adreno: Fix snapshot BINDLESS_DATA sizeRob Clark1-1/+1
The incorrect size was causing "CP | AHB bus error" when snapshotting the GPU state on a6xx gen4 (a660 family). Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/26 Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Akhil P Oommen <[email protected]> Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Patchwork: https://patchwork.freedesktop.org/patch/546763/
2023-07-15drm/msm/a690: Remove revn and nameRob Clark2-3/+2
These fields are deprecated. But any userspace new enough to support a690 also knows how to identify the GPU based on chip-id. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545552/
2023-07-15drm/msm/adreno: Fix warn splat for devices without revnRob Clark1-3/+6
Recently, a WARN_ON() was introduced to ensure that revn is filled before adreno_is_aXYZ is called. This however doesn't work very well when revn is 0 by design (such as for A635). Cc: Konrad Dybcio <[email protected]> Fixes: cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before being set") Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Tested-by: Abhinav Kumar <[email protected]> # sc7280 Patchwork: https://patchwork.freedesktop.org/patch/545554/
2023-07-13drm/msm/dsi: Drop unused regulators from QCM2290 14nm DSI PHY configMarijn Suijten1-2/+0
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: 572e9fd6d14a ("drm/msm/dsi: Add phy configuration for QCM2290") Signed-off-by: Marijn Suijten <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/544536/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]>
2023-07-13drm/msm/dpu: drop enum dpu_core_perf_data_bus_idDmitry Baryshkov1-13/+0
Drop the leftover of bus-client -> interconnect conversion, the enum dpu_core_perf_data_bus_id. Fixes: cb88482e2570 ("drm/msm/dpu: clean up references of DPU custom bus scaling") Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546048/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]>
2023-07-13drm/msm/dpu: add missing flush and fetch bits for DMA4/DMA5 planesJonathan Marek1-1/+7
Note that with this, DMA4/DMA5 are still non-functional, but at least display *something* in modetest instead of nothing or underflow. Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550") Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Patchwork: https://patchwork.freedesktop.org/patch/545548/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]>
2023-07-13drm/msm/mdss: correct UBWC programming for SM8550Dmitry Baryshkov1-2/+17
The SM8550 platform employs newer UBWC decoder, which requires slightly different programming. Fixes: a2f33995c19d ("drm/msm: mdss: add support for SM8550") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546934/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]>
2023-07-11drm/msm/dpu: drop empty features mask INTF_SDM845_MASKDmitry Baryshkov3-10/+0
The INTF_SDM845_MASK features mask is zero. Drop it completely. Reviewed-by: Marijn Suijten <[email protected]> Tested-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545386/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: drop empty features mask MERGE_3D_SM8150_MASKDmitry Baryshkov8-25/+0
The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely. Reviewed-by: Marijn Suijten <[email protected]> Tested-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545384/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macrosDmitry Baryshkov16-209/+545
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: Marijn Suijten <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545378/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline WB_BLK macrosDmitry Baryshkov4-24/+36
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: Marijn Suijten <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545380/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline various PP_BLK_* macrosDmitry Baryshkov16-210/+527
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: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545371/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline MERGE_3D_BLK macrosDmitry Baryshkov8-34/+99
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: Marijn Suijten <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545382/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macrosDmitry Baryshkov13-56/+189
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: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545370/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline LM_BLK macrosDmitry Baryshkov16-133/+487
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: Marijn Suijten <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545362/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline DSPP_BLK macrosDmitry Baryshkov16-88/+215
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: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545359/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: inline SSPP_BLK macrosDmitry Baryshkov16-196/+751
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: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545377/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: correct indentation for CTL definitionsDmitry Baryshkov15-360/+309
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: Marijn Suijten <[email protected]> Tested-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545374/ Link: https://lore.kernel.org/r/[email protected]
2023-07-11drm/msm/dpu: drop zero features from dpu_ctl_cfg dataDmitry Baryshkov2-6/+0
Drop useless zero assignments to the dpu_ctl_cfg::features field. Reviewed-by: Marijn Suijten <[email protected]> Tested-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/545366/ Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.