- 21 Jan, 2023 6 commits
-
-
Dmitry Baryshkov authored
Add qcom,sc8280xp-edp to the list of eDP devices, unblocking `aux-bus' property and fobidding `#sound-dai-cells' property. Also since sc8280xp-edp, overriding sc8280xp-dp, will contain 5 reg resources, drop the reg contraint (as it will become equivalent to the top-level one, requiring min 4 and max 5 reg entries). Fixes: b6f8c4de ("dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles") Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/518797/ Link: https://lore.kernel.org/r/20230118031718.1714861-1-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Describe missing dpu_encoder_phys_wb_is_master() argument and struct dpu_encoder_virt.wide_bus_en field. Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/518794/ Link: https://lore.kernel.org/r/20230118020549.1690078-1-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
According to the discussion ([1]) on the mailing list, platforms before sm8250 (and derivatives) should program HDMI_DP_CORE_SELECT register to route audio to the DP ports. Enable DPU_MDP_AUDIO_SELECT on sc8180x to program correponding register. [1] https://lore.kernel.org/all/f86504ba-835a-6e30-6c30-8bb89b1359c4@quicinc.com/Signed-off-by:
-
Dmitry Baryshkov authored
Rewrite dpu_hw_ctl_setup_blendstage() to use static data configuration rather than using a switch-case. This simplifies adding support for new pipes. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550 Patchwork: https://patchwork.freedesktop.org/patch/518485/ Link: https://lore.kernel.org/r/20230116063316.728496-3-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Extract the common expression in the dpu_hw_ctl_setup_blendstage() function. Signed-off-by:
-
Dmitry Baryshkov authored
SM8550 uses new register to map SSPP_DMA4 and SSPP_DMA5 units to blend stages. Add proper support for this register to allow using these two planes for image processing. Fixes: efcd0107 ("drm/msm/dpu: add support for SM8550") Cc: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
- 18 Jan, 2023 5 commits
-
-
Dmitry Baryshkov authored
According to the vendor dts files, both sc7180 and sc7280 support the source split mode (using two LMs for a single output). Change these two platforms to use MIXER_SDM845_MASK, which includes DPU_MIXER_SOURCESPLIT. Rename MIXER_SC7180_MASK to MIXER_QCM2290_MASK, since this platform doesn't seem to support source split mode. Signed-off-by:
-
Dmitry Baryshkov authored
For each CRTC we are creating two different debugfs directories one using crtc index (created automatically for the CRC files) and another one using CRTC name/object ID (for state and status files). This can be confusing, so move our custom files to crtc->debugfs_entry, effetively merging two debugfs dirs. Signed-off-by:
-
Marijn Suijten authored
In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in "drm/msm/dpu: Reject topologies for which no DSC blocks are available") remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs). To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn't increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform. ^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context. Fixes: bb00a452 ("drm/msm/dpu: Refactor resource manager") Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
-
Dmitry Baryshkov authored
Struct dpu_encoder_virt_ops is used to provide several callbacks to the phys_enc backends. However these ops are static and are not supposed to change in the foreseeble future. Drop the indirection and call corresponding functions directly. Signed-off-by:
-
Konrad Dybcio authored
Add bindings for the display hardware on SM8150. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
-
- 12 Jan, 2023 25 commits
-
-
Marijn Suijten authored
These DSC blocks on CTL V1 need to set its corresponding PINGPONG block index in a hardware register to configure where to send pixel output to, via the newly-added DPU_DSC_OUTPUT_CTRL feature flag. Signed-off-by:
-
Marijn Suijten authored
All V1 CTL blocks (active CTLs) explicitly bind the pixel output from a DSC block to a PINGPONG block by setting the PINGPONG index in a DSC hardware register. Signed-off-by:
-
Marijn Suijten authored
Downstream calls this num_enc yet the DSC patches introduced a new num_dsc struct member, leaving num_enc effectively unused. Fixes: 7e9cc175 ("drm/msm/disp/dpu1: Add support for DSC in topology") Signed-off-by:
-
Marijn Suijten authored
Resource allocation of DSC blocks should behave more like LMs and CTLs where NULL resources (based on initial hw_blk creation via definitions in the catalog) are skipped ^1. The current hardcoded mapping of DSC blocks however means that resource allocation shouldn't succeed at all when the DSC block on the corresponding index doesn't exist, rather than searching for the next free block. This hardcoded mapping should be loosened separately as DPU 5.0.0 introduced a crossbar where DSC blocks can be "somewhat" freely bound to any PP and CTL (in proper pairs). ^1: which, on hardware that supports DSC, can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context. Fixes: f2803ee9 ("drm/msm/disp/dpu1: Add DSC support in RM") Signed-off-by:
-
Marijn Suijten authored
According to downstream /and the comment copied from it/ this comparison should be the other way around. In other words, when the panel driver requests to use more slices per packet than what could be sent over this interface, it is bumped down to only use a single slice per packet (and strangely not the number of slices that could fit on the interface). Fixes: 08802f51 ("drm/msm/dsi: Add support for DSC configuration") Signed-off-by:
-
Marijn Suijten authored
According to downstream the value to use for WORD_COUNT is bytes_per_pkt, which denotes the number of bytes in a packet based on how many slices have been configured by the panel driver times the width of a slice times the number of bytes per pixel. The DSC panels seen thus far use one byte per pixel, only one slice per packet, and a slice width of half the panel width leading to the desired bytes_per_pkt+1 value to be equal to hdisplay/2+1. This however isn't the case anymore for panels that configure two slices per packet, where the value should now be hdisplay+1. Note that the aforementioned panel (on a Sony Xperia XZ3, sdm845) with slice_count=1 has also been tested to successfully accept slice_count=2, which would have shown corrupted output previously. Fixes: 08802f51 ("drm/msm/dsi: Add support for DSC configuration") Signed-off-by:
-
Marijn Suijten authored
Active CTLs have to configure what DSC block(s) have to be enabled, and what DSC block(s) have to be flushed; this value was initialized to zero resulting in the necessary register writes to never happen (or would write zero otherwise). This seems to have gotten lost in the DSC v4->v5 series while refactoring how the combination with merge_3d was handled. Fixes: 58dca981 ("drm/msm/disp/dpu1: Add support for DSC in encoder") Signed-off-by:
-
Neil Armstrong authored
Add support for the MDSS block on SM8550 platform. Signed-off-by:
-
Neil Armstrong authored
Add definitions for the display hardware used on Qualcomm SM8550 platform. Reviewed-by:
-
Bjorn Andersson authored
Add compatible for the SC8280XP Mobile Display Subsystem and initialization for version 8.0.0. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514402/ Link: https://lore.kernel.org/r/20221207220012.16529-4-quic_bjorande@quicinc.comSigned-off-by:
-
Bjorn Andersson authored
The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9 interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the necessary definitions and describe the DPU in the SC8280XP. Signed-off-by:
-
Bjorn Andersson authored
Add binding for the display subsystem and display processing unit in the Qualcomm SC8280XP platform. Signed-off-by:
-
Robert Foss authored
Add compatibles string, "qcom,sm8350-mdss", for the multimedia display subsystem unit used on Qualcomm SM8350 platform. Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
SM8350 has newer version of DSC blocks, which are not supported by the driver yet. Remove them for now until these blocks are supported by the driver. Signed-off-by:
-
Robert Foss authored
Add compatibles string, "qcom,sm8350-dpu", for the display processing unit used on Qualcomm SM8350 platform. Signed-off-by:
-
Robert Foss authored
Add compatibility for SM8350 display subsystem, including required entries in DPU hw catalog. Signed-off-by:
-
Robert Foss authored
Mobile Display Subsystem (MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for MDSS device tree bindings Signed-off-by:
-
Robert Foss authored
Mobile Display Subsystem (MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for DPU device tree bindings Signed-off-by:
-
Dmitry Baryshkov authored
Add support for the MDSS block on SM8450 platform. Tested-by:
Vinod Koul <vkoul@kernel.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Reviewed-by:
-
Dmitry Baryshkov authored
Add definitions for the display hardware used on Qualcomm SM8450 platform. Tested-by:
-
Dmitry Baryshkov authored
On sm8450 a register block was removed from MDP TOP. Accessing it during snapshotting results in NoC errors / immediate reboot. Skip accessing these registers during snapshot. Tested-by:
-
Dmitry Baryshkov authored
There is a separate header containing some of MDP TOP register definitions, dpu_hwio.h. Move missing register definitions from dpu_hw_top.c to the mentioned header. Signed-off-by:
-
Dmitry Baryshkov authored
Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm SM8450 platform. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Dmitry Baryshkov authored
Require only properties declared in given schema, which makes the code a bit more readable and easy to follow. Suggested-by:
-
Krzysztof Kozlowski authored
The Devicetree bindings document does not have to say in the title that contains "DT properties", but instead just describe the hardware. Signed-off-by:
-
- 08 Jan, 2023 3 commits
-
-
Marijn Suijten authored
The mask only describes the `irq_idx % 32` part, making it generally impossible to deduce what interrupt is being enabled/disabled. Since `debug/core_irq` in debugfs (and other prints) also include the full `DPU_IRQ_IDX()` value, print the same full value here for easier correlation instead of only adding the `irq_idx / 32` part. Furthermore, make the dbgstr messages more consistent. Signed-off-by:
Martin Botka <martin.botka@somainline.org> Reviewed-by:
-
Hui Tang authored
Because of the possilble failure of devm_kzalloc(), dpu_wb_conn might be NULL and will cause null pointer dereference later. Therefore, it might be better to check it and directly return -ENOMEM. Fixes: 77b001ac ("drm/msm/dpu: add the writeback connector layer") Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
-
Konrad Dybcio authored
SDM845 only has INTF0-3 and has no business caring about the INTF4 irq. Suggested-by:
-
- 05 Jan, 2023 1 commit
-
-
Akhil P Oommen authored
As per the downstream driver, gx gbif halt is required only during recovery sequence. So lets avoid it during regular rpm suspend. Signed-off-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/515279/ Link: https://lore.kernel.org/r/20221216223253.1.Ice9c47bfeb1fddb8dc377a3491a043a3ee7fca7d@changeidSigned-off-by:
Rob Clark <robdclark@chromium.org>
-
